By: anon (anon.delete@this.anon.com), August 11, 2014 6:21 am
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on August 11, 2014 5:43 am wrote:
> anon (anon.delete@this.anon.com) on August 11, 2014 4:10 am wrote:
> >
> > I refuse to believe that anybody at Intel ever thought the trace cache would be a walk in the park. They
> > may have over estimated their ability to overcome the obvious problems, but they were clearly considering
> > this in context of improving decoding stages by other means. Ergo they were struggling with decode.
> >
>
> But 2-way x86 decoding is known to be not hard, even in absence of pre-parsed stop bits in ICache.
> Decision of P55C designers to abandon stop bits technique
> used by P5/P54 looks to me as a good enough evidence.
That assumes stop bits were abandoned for a good reason, and not due to bad set of simulations :)
More seriously, that assumes that stop bits were simple and made decoding "easy". Without those assumptions, there could be many other possiblities. They might have been more costly than appeared, or they might not have really made decoding significantly easier, for example.
> Despite that, Pentium4 designers went with 1-way primary decoder instead of 2-way. With an insight
> that we have now it looks like they just relied on bad set of simulation vectors (too loopy) that
> underestimated real-world impact of narrow decoder and lead to wrong technical decision.
I don't know if the Pentium 1 insight maps too well to the Pentium 4. With a trace cache, decode requirement should still be significantly reduced even for most less-than-optimal loads. And serial decoder is probably significantly simpler than 2-way, and should be made to clock much higher.
At any rate, the fact remains that instead of taking their existing 3-way decode scheme and using or incrementally improving it, they decided to scrap it and invest in a vast and unproven new design. However incompetent or naive or whatever people want to believe Intel were, that undertaking was *not* done because they had so few problems with decoding that they needed to invent some new ones.
> anon (anon.delete@this.anon.com) on August 11, 2014 4:10 am wrote:
> >
> > I refuse to believe that anybody at Intel ever thought the trace cache would be a walk in the park. They
> > may have over estimated their ability to overcome the obvious problems, but they were clearly considering
> > this in context of improving decoding stages by other means. Ergo they were struggling with decode.
> >
>
> But 2-way x86 decoding is known to be not hard, even in absence of pre-parsed stop bits in ICache.
> Decision of P55C designers to abandon stop bits technique
> used by P5/P54 looks to me as a good enough evidence.
That assumes stop bits were abandoned for a good reason, and not due to bad set of simulations :)
More seriously, that assumes that stop bits were simple and made decoding "easy". Without those assumptions, there could be many other possiblities. They might have been more costly than appeared, or they might not have really made decoding significantly easier, for example.
> Despite that, Pentium4 designers went with 1-way primary decoder instead of 2-way. With an insight
> that we have now it looks like they just relied on bad set of simulation vectors (too loopy) that
> underestimated real-world impact of narrow decoder and lead to wrong technical decision.
I don't know if the Pentium 1 insight maps too well to the Pentium 4. With a trace cache, decode requirement should still be significantly reduced even for most less-than-optimal loads. And serial decoder is probably significantly simpler than 2-way, and should be made to clock much higher.
At any rate, the fact remains that instead of taking their existing 3-way decode scheme and using or incrementally improving it, they decided to scrap it and invest in a vast and unproven new design. However incompetent or naive or whatever people want to believe Intel were, that undertaking was *not* done because they had so few problems with decoding that they needed to invent some new ones.
