Architecture of Computing Systems (Lecture Notes in Computer ...

16 G. Aşılıoğlu, E.M. Kaya, and O. Ergin
rename table, walking forward and backwards on the reorder buffer or waiting until
the commit time of the mispredicted branch instruction [2][9]. Each of these schemes
have various pros and cons in terms of circuit complexity and misprediction penalty.
In this paper we propose a new implementation of the rename table that allows fast
recovery on a branch misprediction. We propose to use a FIFO structure for each
architectural register and recover the tail pointers when a branch misprediction occurs.
Our design is less complex than taking a full checkpoint of the rename table, and
has smaller restoration latency when compared to the schemes that walk through the
reorder buffer.
2 Register Renaming
Register renaming requires a new physical register to be assigned to each and every
result producing instruction. Fig. 1 shows an example of how the register renaming is
performed. Note that R1 is overwritten by the second ADD instruction which is in
fact not dependent on the first ADD. This false dependency is removed by assigning
different physical registers to two ADD instructions.
ADD R1, R2, R3
SUB R2, R1, R2
ADD R1, R4, R5
ADD P13, P22, P31
SUB P52, P13, P22
ADD P95, P63, P44
Rename Table
R1 P95
R2 P52
R3 P21
R4 P63
R5 R44
R6 P6
R7 P7
R8 P8
Fig. 1. Example of Register Renaming
The second ADD instruction in Fig. 1 removes its write after write (WAW) and
write after read (WAR) dependencies by writing its result to a separate physical register.
However, this is not enough to maintain precise execution; any younger instruction
that needs to access R1 has to be aware of the fact that the value it needs to read
resides in P95. The rename table is used for this purpose; the table includes an entry
for each architectural register that holds the location of the most recent instance of the
register. Consequently, as the rename table holds the precise state of the processor,
any fault on this table will result in a system crash.
Ideally the rename table idea works perfectly. Each instruction that produces a result
checks the availability of a physical register and allocates a register. Afterwards,
the result producing instruction updates the rename table to inform the consumers that
will later check this table to obtain the location of their architectural source registers.
In superscalar machines, multiple instructions need to be renamed each cycle, which