U. Glaeser

operand fields (V1/V2)
indicate whether the related operand field holds a valid source operand value
(Op1/Op2)
or a rename register identifier ( Rs1′ / Rs2′ ).
(ii) Dispatching is not at all rename specific. Assuming in-order dispatching, the processor inspects
the valid bits of the source operands (V1 and V2) of the oldest instruction kept in the RS. If both valid
bits of this instruction are set and the EU is also free, the instruction is forwarded to the EU for execution.
(iii) After the EU has finished the execution of an instruction, both the RS and the RRF need to be
updated with the generated result. To update the RS, the generated results and their identifiers (Rd′) are
broadcasted to all the source register entries held in the RS. Through an associative search, all source register
identifiers ( Rs1′ , Rs2′ ) are located, which are waiting for the new result. The processor substitutes matching
identifiers with the result value and sets the associated valid bits (V1 or V2) to indicate availability. We
note that this task is performed basically in the same way with and without renaming. There is, however,
a slight difference, with renaming the search key is the renamed destination register identifier (Rd′) rather
than the original destination register identifier (Rd) that is used without renaming. The second task is
to update the rename register file. This is done simply by writing the new result value into the RRF using
the identifier accompanying the result produced (Rd′) and setting the associated valid bit (V) to signal
availability.
(iv) While an instruction completes, the processor permanently updates the ARF, and thus the program state,
with the content of the associated rename register. This is done by writing the result of the completed
instruction from the associated rename register to the addressed destination register. At this stage of the
instruction execution the established renaming becomes obsolete. Therefore, the related entry in the mapping
table needs to be deleted and the rename register involved can be reclaimed for further use. This is so
since (1) after completion, the result of the instruction, that is, the content of the rename register, has already
been written into the addressed destination register, and (2) after finishing the instruction, the generated
result has already been transferred to all instructions waiting for this operand in the RS.
During renaming, rename registers take on a sequence of states, as indicated in Fig. 6.3.
During initialization the processor sets all rename registers into the “available” state. When the processor
allocates a rename register to an issued instruction, the state of the allocated register will be changed
to “allocated, not valid” and its valid bit will be reset. When this instruction becomes finished, the newly
produced result is written into the associated rename register, and its state is set to “allocated, valid.”
Finally, while the instruction completes, the result held temporarily in the rename register is written into
the specified architectural register. Thus, the allocated rename register can be reclaimed. Its state is then
changed to “available.” Nevertheless, it can happen that an exception or faulty speculative execution gives
rise to flush not yet completed instructions. In this case, a recovery procedure is needed, and the state of
FIGURE 6.3 State transition diagram of the rename registers, assuming the use of a rename register file (RRF).
© 2002 by CRC Press LLC
Initialized
Reclaim, if instruction
is completed
Available
Allocate, if instruction
is issued
Allocated,
valid
Reclaim,
if instruction
is canceled
Allocated,
not valid
Update, if instruction
is finished