DOC PREVIEW
O-K-State ECEN 6253 - Register Renaming

This preview shows page 1-2 out of 7 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 7 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Register Renaming1. source read: The decode or dispatch stage must find the source operand values to pass onto the execution stage.a. ARF.Busy = 0: The correct value is read from the ARF.b. ARF.Busy = 1 and RRF.Valid = 1: The correct value is read from the RRF.c. ARF.Busy = 1 and RRF.Valid = 0: The value has not yet been calculated. The tag is passed instead to the reservation station where the instruction waits for the value to be calculated before starting execution.2. destination allocate: The decode or dispatch stage must find a rename register to use for the destination operand value.a. Find a register in the RRF with RRF.Busy = 0 and set its RRF.Busy = 1 and RRF.Valid = 0. To avoid repeatedly reading the RRF.Busy values, the RRF.Busy bits are hardwired to a priority encoder which selects the first unused RRF register(s).b. copy the RRF register number from step 2a into the tag field of the architected register in the ARF and simultaneously set its ARF.Busy = 1.3. rename register update: The execution finish stage must store the destination operand value into the rename register.a. The destination tag (passed to execution by dispatch) is used to select a rename register in the RRF.b. The destination value is written from the end of the execute pipeline into the selected rename register and simultaneously sets RRF.Valid = 1.4. architected register update: The complete stage takes the instruction at the top of the reorder buffer and copies the data from the RRF to the ARF, waiting for the valid bit to be set if necessary.a. If RRF.Valid = 0, the destination data is not ready and completion cannot take place.b. If RRF.Valid = 1, completion takes place by copying RRF.data to ARF.data and freeing the rename register by resetting RRF.Busy = 0. If ARF.Tag = RRF register number, then reset ARF.Busy = 0.5. mispredicted branch recovery: When a mispredicted branch is at the top of the reorder buffer, the complete stage discards the rename registers by setting RRF.Busy = 0 and ARF.Busy = 0 for all entries in the RRF and ARF.Pooled Register FileOSU Virtual Register Design1. source read: The decode or dispatch stage must find the source operand values to pass onto the execution stage.a. Use the register number in the instruction to read the ARP and RRP to get the physical register pointer to the RF. If RRP.Val...b. If RF.Valid = 1: The correct value is read from the RF.c. If RF.Valid = 0: The value has not yet been calculated. The physical register pointer is passed instead to the reservation station where the instruction waits for the value to be calculated before starting execution.2. destination allocate: The decode or dispatch stage must find a rename register to use for the destination operand value.a. Find a register in the RF with RF.Busy = 0 and set its RF.Busy = 1 and RF.Valid = 0. To avoid repeatedly reading the RF.Busy values, the RF.Busy bits are hardwired to a priority encoder which selects the first unused RF register(s).b. copy the RF register number from step 2a into the RRP.3. rename register update: The execution finish stage must store the destination operand value into the rename register.a. The (renamed) physical register number (passed to execution by dispatch) is used to select a register in the RF.b. The destination value is written from the end of the execute pipeline into the selected register and simultaneously sets RF.Valid = 1.4. architected register update: The complete stage takes the instruction at the top of the reorder buffer and changes the ARP to point to the new physical register, waiting for the valid bit to be set if necessary.a. If RF.Valid = 0, the destination data is not ready and completion cannot take place.b. If RF.Valid = 1, completion takes place by copying physical register number to ARP and setting RF.Busy = 0 for the old register.5. mispredicted branch recovery: When a mispredicted branch is at the top of the reorder buffer, the complete stage discards the rename registers by setting RRP.Valid = 0 for all entries in the RRP.ECEN 6253 Advanced Digital Computer Design Register Renaming January 17, 2006 page 1 of 7Register RenamingRecall from our earlier discussion of instruction level parallelism (ILP) that name depen-dences arise from reuse of the same register for different data. The two kinds of name dependence, anti-dependence (WAR hazard) and output dependence (WAW hazard), both write new data to a register which must not occur until after previous instructions have fin-ished reading or writing the register.Name dependences can be eliminated by using new registers for new data so that each reg-ister is written only once. Since nothing is in the register before writing into the register for the first time, there are no name dependences. Completely eliminating name dependences is not practical for a real processor with a finite number of registers. The compiler is limited to the architected set of registers. For example, the MIPS instruction set has 32 (31 really if you do not count R0) architected registers that must be reused to do all the different calculations in a program. Code gener-ated by compilers typically has many name dependences.With the large number of transistors in modern processors, there is no reason to limit the hardware implementation to just the architected registers. We can provide extra internal registers (rename registers) invisible to the programmer for writing new data values. As long as we do not run out of rename registers, name dependences are avoided and instruc-tions with name dependences can be allowed to execute in parallel.Actually we have already provided rename registers in the reorder/completion buffer. Instruction results (data) are stored (written) there after execution finish until the instruc-tions are completed (data written to the architected registers) in program order. The stor-age in the reorder/completion buffer serves as rename registers.Hardware implementation may have the rename registers in a separate Rename Register File (RRF) or as part of the reorder buffer (fig. 5-15, p. 240). The register specifier input to the Architected Register File (ARF) is the architected register from the instruction code. The busy bit is set when a (non-completed) instruction will write into the architected reg-ister at a later time. The tag points to the location in the RRF where the new value will be stored. The valid bit in the RRF is set when the new data is written after execution of the


View Full Document

O-K-State ECEN 6253 - Register Renaming

Documents in this Course
Load more
Download Register Renaming
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Register Renaming and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Register Renaming 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?