U. Glaeser

In this case, however, during instruction execution a rename buffer becomes an architectural register
and reclaiming is related to no longer used architectural registers, as discussed in the section on “Types
of Rename Buffers.” This method relies on keeping track of the most recent prior instance of the same
architectural register, and on reclaiming it when the instruction giving rise to the new instance completes. 28
Renaming of Destination and Source Registers if Inter-Instruction Dependencies Exist
between the Instructions Issued in the Same Cycle
As we know, shelving relieves the processor of the need to check for data- and control dependencies as
well as for busy EUs during instruction issue. Nevertheless, despite shelving, instructions issued in the
same cycle must still be checked for inter-instruction dependencies, and, in the case of dependencies,
the rename logic must be modified accordingly. Let us assume, for instance, that there are RAW dependencies
between two subsequent instructions issued in the same cycle, as in the following example:
© 2002 by CRC Press LLC
i 1: mul r 2,…,…
i 2: add …,r 2,…
Here, i 2 needs the result of i 1 as r 2 is one of its source operands. We will also assume that the destination
register of i 1 (r 2) will be renamed to r 33 as follows:
i1′ : mul r33,…,… In this case the RAW-dependent source operand of i 2 (r 2) has to be renamed to r 33 rather than to the
rename buffer allocated before renaming of i 1 to r 2.
Similarly, if WAW dependencies exist among the instructions issued in the same cycle, as for instance,
between the instructions
i 1: mul r 2,…,…
i 2: add r 2,…,…
obviously, different rename buffers need to be allocated to the destination registers of i 1 and i 2, as shown
below:
i1′ : mul r34,…,… i2′ : add r35,…,… Recovery of the Rename Process from Wrongly Executed Speculation
and Handling of Exceptions
If the processor performs speculative execution, for instance due to branch prediction, it may happen
that the speculation turns out to be wrong. In this case the processor needs to recover from the misspeculation.
This involves essentially two tasks: (i) to undo all register mappings set up, and (ii) to reclaim
rename buffers allocated, as already discussed. To invalidate established mappings there are two basic
methods to choose from, independently of the actual implementation of renaming. The first option is
to roll back all register mappings made during speculative execution, by using the identifiers of the faulty
instructions, supplied by the ROB. While using this alternative, the recovery process lasts several cycles,
since the processor can cancel only a small number of instructions (two to four) per cycle. A second
alternative is based on checkpointing. In this method, before the processor begins with speculative
execution, it saves the relevant machine state, including also the actual mapping, in shadow registers. If
the speculative execution turns out to be wrong, the processor restores the machine state in a single cycle
by reloading the saved state. For instance, both the PM1 (Sparc64) and the R10000 use checkpointing