The Rename Stage¶

The Rename stage maps the ISA (or logical) register specifiers of each instruction to physical register specifiers.

The Purpose of Renaming¶

Renaming is a technique to rename the ISA (or logical) register specifiers in an educational activity by mapping them to a new space of physical registers. The goal to register renaming is to interruption the output-dependencies (WAW) and anti-dependences (WAR) betwixt instructions, leaving only the truthful dependences (RAW). Said again, but in architectural terminology, register renaming eliminates write-after-write (WAW) and write-afterward-read (War) hazards, which are artifacts introduced by a) only having a limited number of ISA registers to apply as specifiers and b) loops, which by their very nature will use the aforementioned annals specifiers on every loop iteration.

The Explicit Renaming Blueprint¶

PRF vs Data-in-ROB design

Fig. 14 A PRF blueprint (left) and a information-in-ROB pattern (right)

BOOM is an "explicit renaming" or "physical register file" out-of-order core design. A Physical Register File, containing many more registers than the ISA dictates, holds both the committed architectural register state and speculative register country. The Rename Map Table s contain the information needed to recover the committed state. As instructions are renamed, their annals specifiers are explicitly updated to signal to concrete registers located in the Physical Register File. [1]

This is in contrast to an "implicit renaming" or "data-in-ROB" out-of-order core design. The Architectural Annals File (ARF) only holds the committed register state, while the ROB holds the speculative write-dorsum information. On commit, the ROB transfers the speculative data to the ARF[2]_

The Rename Map Table¶

The Rename Stage

Fig. 15 The Rename Stage. Logical register specifiers read the Rename Map Table to get their physical specifier. For superscalar rename, any changes to the Map Tables must be bypassed to dependent instructions. The physical source specifiers can then read the Busy Table. The Stale specifier is used to runway which physical register will be freed when the pedagogy later commits. P0 in the Physical Register File is always 0.

The Rename Map Table (abbreviated as Map Table) holds the speculative mappings from ISA registers to concrete registers.

Each branch gets its own copy of the Rename Map Table[three]_ On a co-operative mispredict, the Rename Map Tabular array can be reset instantly from the mispredicting branch's copy of the Rename Map Table

Equally the RV64G ISA uses fixed locations of the register specifiers (and no implicit register specifiers), the Map Table can be read before the teaching is decoded! And hence the Decode and Rename stages tin be combined.

Resets on Exceptions and Flushes¶

An additional, optional "Committed Map Tabular array" holds the rename map for the committed architectural country. If enabled, this allows unmarried-cycle reset of the pipeline during flushes and exceptions (the electric current map table is reset to the Committed Map Table). Otherwise, pipeline flushes require multiple cycles to "unwind" the ROB to write dorsum in the rename state at the commit point, 1 ROB row per bicycle.

The Busy Tabular array¶

The Decorated Table tracks the readiness status of each concrete register. If all physical operands are ready, the instruction will exist ready to be issued.

The Free List¶

The Free Listing tracks the physical registers that are currently un-used and is used to allocate new physical registers to instructions passing through the Rename stage.

The Complimentary Listing is implemented as a scrap-vector. A priority decoder can and so be used to find the first free register. Blast uses a cascading priority decoder to allocate multiple registers per bicycle. [iv]

On every branch (or JALR), the Rename Map Tables are snapshotted to allow single-cycle recovery on a branch misprediction. Likewise, the Complimentary List also sets bated a new "Allocation List", initialized to nothing. As new physical registers are allocated, the Allocation List for each branch is updated to track all of the physical registers that have been allocated after the branch. If a misspeculation occurs, its Allocation List is added back to the Free List by OR'ing the co-operative's Resource allotment Listing with the Free Listing. [5]

Dried Destination Specifiers¶

For instructions that will write a register, the Map Table is read to get the stale concrete destination specifier ("stale pdst"). Once the instruction commits, the stale pdst is returned to the Free List, equally no future instructions volition read it.

[1] The MIPS R10k, Blastoff 21264, Intel Sandy Bridge, and ARM Cortex A15 cores are all example of explicit renaming out-of-social club cores.
[ii] The Pentium 4 and the ARM Cortex A57 are examples of implicit renaming designs.
[three] An alternating design for wider pipelines may prefer to only brand upwards to one snapshot per cycle, just this comes with additional complexity to deduce the precise mappings for any given educational activity within the Fetch Parcel.
[4] A two-wide Rename phase could apply two priority decoders starting from opposite ends.
[5] Conceptually, branches are ofttimes described equally "snapshotting" the Complimentary List (along with an OR'ing with the electric current Free List at the time of the misprediction). Even so, snapshotting fails to business relationship for physical registers that were allocated when the snapshot occurs, and then become freed, and then becomes re-allocated earlier the branch mispredict is detected. In this scenario, the physical annals gets leaked, every bit neither the snapshot nor the current Free List know that it had been freed. Somewhen, the processor slows as it struggles to maintain enough inflight concrete registers, until finally the machine comes to a halt. If this sounds autobiographical because the original author (Chris) may accept trusted computer architecture lectures, well…