anon (spam.delete.delete@this.this.spam.com) on May 8, 2017 3:15 am wrote:
> Brett (ggtgp.delete@this.yahoo.com) on May 8, 2017 2:38 am wrote:
> > anon (spam.delete.delete@this.this.spam.com) on May 8, 2017 1:39 am wrote:
> > > Brett (ggtgp.delete@this.yahoo.com) on May 7, 2017 8:57 pm wrote:
> > > > anon (spam.delete.delete@this.this.spam.com) on May 7, 2017 5:47 pm wrote:
> > > > > Brett (ggtgp.delete@this.yahoo.com) on May 7, 2017 1:56 pm wrote:
> > > > > > anon (spam.delete.delete@this.this.spam.com) on May 6, 2017 4:41 pm wrote:
> > > > > > > Brett (ggtgp.delete@this.yahoo.com) on May 6, 2017 3:16 pm wrote:
> > > > > > > > anon (spam.delete.delete@this.this.spam.com) on April 21, 2017 1:19 pm wrote:
> > > > > > > > > NoSpammer (no.delete@this.spam.com) on April 21, 2017 12:40 pm wrote:
> > > > > > > > > > anon (spam.delete.delete@this.this.spam.com) on April 21, 2017 7:55 am wrote:
> > Belt positions are unique.
>
> They are not. The belt "moves". So the same position points to a different value depending
> on the cycle. Therefore you can't change the order of execution unless you rename.
>
> >
> > > How do you recover from a mispredict.
> >
> > Roll back the belt, and any writes.
> >
>
> And how do you do that, if you haven't saved?
>
> > > Any changes in execution order and values be not in the same positions on the belt.
> >
> > No, belt positions are assigned at decode. Trying to assign
> > belt positions at execution time would not work.
> >
>
> Belt "positions" are assigned at compile time. Based on when the previous instructions finish.
> The position of a result is implicit. Again, if the execution order
> changes the result does not end up in the same position.
>

This is why this looks like a job for runahead. Warning: while it looks good in theory, expect runahead to multiply checkpointed belt saves like rabbits. You need to have a few belts worth of saved data just for runahead (for a naive one anyway, I doubt a complex one could restore fast enough) and expect to check point all of that each branch. Andy Glew talks about the "log issue" on his wiki, I suspect this is what he means.

And then expect all the fun in retiring stores from OoO, while leaving plenty of OoO benefits on the table. It might work ok if you have short belts (and the circuit design of the checkpoints seems similar to a belt, I suspect they will play reasonably nicely).

And this is why x86/AMD64 and RISC survive and thrive. Not because they are designed for a post-RISC world, but because you don't have to fight them so much to get them to work in modern designs. You might get away with an architecture that assumes Moore's law is dead *now*, but don't expect customers to lock themselves in right away (because historically it has been such a bad bet).