By: Michael S (already5chosen.delete@this.yahoo.com), August 11, 2014 5:43 am
Room: Moderated Discussions
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.
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 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.
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.
