By: David Kanter (dkanter.delete@this.realworldtech.com), April 21, 2015 8:26 am
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.
Byte addressing isn't exactly free...and flip-flops aren't exactly that expensive. I'd argue the RF ports are the problem.
David
> 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.
Byte addressing isn't exactly free...and flip-flops aren't exactly that expensive. I'd argue the RF ports are the problem.
David