By: Brett (ggtgp.delete@this.yahoo.com), April 20, 2015 5:43 pm
Room: Moderated Discussions
Ivan Godard (ivan.delete@this.millcomputing.com) on April 20, 2015 5:34 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on April 19, 2015 11:13 am wrote:
>
> >
> > How about an even simpler analysis?
> > The most interesting and important part of Mill is the (I
> > think correct) intuition that most register data is
> > temporary: it's read off the bypass network, goes through
> > an EU, and the result is again read off the bypass
> > network. As such, the machinery that exists for giving it
> > a name is pointless overhead, and the ideal situation
> > would be an ISA that did not require giving these sorts of temporaries a name, with all that implies.
> >
> > The question, then, is
> > (a) how can you do this?
> > (b) how do you deal with the fraction of register data that is NOT of this form?
> > There is also a third (implementation, rather than architectural) issue of what you do when an interrupt
> > occurs. It seems like you could just drain in-flight instructions, but you have the problem of all
> > those successor instructions that were expecting to pull their data off the bypass network.
>
> That's why the Mill uses result replay rather than issue replay.
>
> > An apparently similar (but perhaps quite different) problem is
> > that of maintaining backup state across speculation points.
>
> There is no backup, nor speculation points. Speculated data is
> just like regular data, except it may get thrown away later.
>
> > Registers (ie NAMED registers) are useful enough that one
> > suspects one wants the ISA to provide them, and at
> > least 8 of them.
>
> Don't use registers; it's a waste of flip-flops because they all have to be max
> size. Our scratchpad SRAM is byte-addressable, so you can pack the data the same
> way you would pack data in a stack frame. Saves power and bandwidth.
What do loads look like and where do they go, to the ALU or scratchpad or either?
> > But I think it is true that un-named data that's accessed more or less implicitly is conceptually
> > an important insight. The question is: can you use this insight to improve the core while still
> > - providing some named registers
> > - dealing with interrupts and speculation
> > - given that you want to provide some named registers, and that you want some sort of background
> > storage to handle interrupts and speculation, does the win (some ISA bits, maybe smaller
> > remap structures) from not visibly naming most of your in-flight data buy you enough to
> > be worth boiling the ocean (new compiler ideas, new micro-architectural ideas)?
> >
>
> The encoding gain is significant but relatively unimportant. The real gain is from the intermediates
> being single-assignment, so there are no pipe hazards nor any need for scoreboarding etc.
> Maynard Handley (name99.delete@this.name99.org) on April 19, 2015 11:13 am wrote:
>
> >
> > How about an even simpler analysis?
> > The most interesting and important part of Mill is the (I
> > think correct) intuition that most register data is
> > temporary: it's read off the bypass network, goes through
> > an EU, and the result is again read off the bypass
> > network. As such, the machinery that exists for giving it
> > a name is pointless overhead, and the ideal situation
> > would be an ISA that did not require giving these sorts of temporaries a name, with all that implies.
> >
> > The question, then, is
> > (a) how can you do this?
> > (b) how do you deal with the fraction of register data that is NOT of this form?
> > There is also a third (implementation, rather than architectural) issue of what you do when an interrupt
> > occurs. It seems like you could just drain in-flight instructions, but you have the problem of all
> > those successor instructions that were expecting to pull their data off the bypass network.
>
> That's why the Mill uses result replay rather than issue replay.
>
> > An apparently similar (but perhaps quite different) problem is
> > that of maintaining backup state across speculation points.
>
> There is no backup, nor speculation points. Speculated data is
> just like regular data, except it may get thrown away later.
>
> > Registers (ie NAMED registers) are useful enough that one
> > suspects one wants the ISA to provide them, and at
> > least 8 of them.
>
> Don't use registers; it's a waste of flip-flops because they all have to be max
> size. Our scratchpad SRAM is byte-addressable, so you can pack the data the same
> way you would pack data in a stack frame. Saves power and bandwidth.
What do loads look like and where do they go, to the ALU or scratchpad or either?
> > But I think it is true that un-named data that's accessed more or less implicitly is conceptually
> > an important insight. The question is: can you use this insight to improve the core while still
> > - providing some named registers
> > - dealing with interrupts and speculation
> > - given that you want to provide some named registers, and that you want some sort of background
> > storage to handle interrupts and speculation, does the win (some ISA bits, maybe smaller
> > remap structures) from not visibly naming most of your in-flight data buy you enough to
> > be worth boiling the ocean (new compiler ideas, new micro-architectural ideas)?
> >
>
> The encoding gain is significant but relatively unimportant. The real gain is from the intermediates
> being single-assignment, so there are no pipe hazards nor any need for scoreboarding etc.