Computers spend most of their time in loops, so multiple loop iterations are great places to speculatively find more work to keep CPU resources busy. Nothing is ever easy, though; the compiler emitted only one copy of that loop's code, so even though multiple iterations are handling distinct data, they will appear to use the same registers. To keep register usages multiple iterations from colliding, we rename their registers. Figure 2.36 shows example code that we would like our hardware to rename.
A compiler could have simply unrolled the loop and used different registers to avoid conflicts, but if we expect our hardware to unroll the loop, it must also do the register renaming. How? Assume your hardware has a pool of temporary registers (call them T registers, and assume there are 64 of them, T0 through T63) that it can substitute for those registers designated by the compiler. This rename hardware is indexed by the source register designation, and the value in the table is the T register of the last destination that targeted that register. (Think of these table values as producers, and the src registers are the consumers; it doesn't much matter where the producer puts its result as long as its consumers can find it.) Consider the code sequence in Figure 2.36. Every time you see a destination register in the code, substitute the next available T, beginning with T9. Then update all the src registers accordingly, so that true data dependences are maintained. Show the resulting code.

Figure 2.36 Sample code for register renaming practice.

Figure 2.37 Expected output of register renaming.

Figure 2.38 Sample code for superscalar register renaming.

Loop: LD F2,0 (Rx) I0 MULTD F5,FO, F2 DIVD F8, FO, F2 I2: LD F4,0 (Ry) 13: ADDD F6, FO, F4 14: ADDD F10,F8,F2 I5: SD F4,0 (Ry) I0: LD T9,0 (Rx) Il: MULTD T10, FO, T9 I0: MULTD F5,FO,F2 I1 ADDD F9,F5, F4 I2: ADDD F5, F5, F2 13: DIVD F2,F9, FO