Patrick Chase (patrickjchase.delete@this.gmail.com) on February 4, 2013 1:08 pm wrote:
> Patrick Chase (patrickjchase.delete@this.gmail.com) on February 4, 2013 12:48 pm wrote:
> > 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.
>
> Execpt of course that the P6 wasn't a "classic" RS design. The uops/RS entries point
> to either the architectural register file or to ROB entries rather than holding literal/virtual
> values as in, say, the 360/91 FP unit. Results on the common bus are tagged with ROB
> entry number instead of RS slot ID. Should have looked it up first...

Sorry about the spam, but I was more correct the first time.

In the P6 the architectural register file was read during issue (for integer ops at least), which meant that the uop (what is sent from issue to RS) did indeed contain literals, hence the 118-bit size. The main difference from classic Tomasulo was in the handling of *virtual* values, but those don't drive the uop size in this case.

-- Patrick