Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 4, 2013 12:20 pm wrote:
> Patrick Chase (patrickjchase.delete@this.gmail.com) on February 4, 2013 10:05 am wrote:
> [snip]
> > You can mitigate such decode power penalties by using a first-level Icache that contains
> > uops instead of instructions. It only works if you're using physical register files (as opposed
> > to reservation stations), though, because otherwise the uop size is unmanageable.
>
> Why would µop size be any different based on the form of renaming?

In a classic reservation station based OoO design the uop (the thing that is sent from the issue unit to the RS after renaming) contains either:

1. The literal value of each input operand if it is available at the time of issue

2. The identity of the reservation station that will produce the input operand, if it is unavailable at the time of issue. The reservation station used this information to "capture" the operand when it is subsequently broadcast to the common result bus (and that's why the result bus is a power-intensive part of a Tomasulo machine).

That makes for a rather large uop. In contrast in the PRF style the uop contains the ID of the physical register. I don't know the uop sizes for P4 or "the bridges", but I'd bet they're considerably smaller than the original P6's reported 118 bits.

Even in the PRF case there has to be some "fixup" of the uop coming out of the I-cache (for example the physical register IDs must change based on the state of the IRAT), so it's not possible to cache "pure" uops. It would presumably be possible to define an intermediate "predecoded" format that could be used in an RS-based design. For some reason I don't know Intel never did so, though. They've very consistently used uop caches in the PRF designs but not in their RS designs.

-- Patrick