Переименование регистров в компьютерной архитектуре

In computer architecture, register renaming is a technique that abstracts logical registers from physical registers. Every logical register has a set of physical registers associated with it. When a machine language instruction refers to a particular logical register, the processor transposes this name to one specific physical register on the fly. The physical registers are opaque and cannot be referenced directly but only via the canonical names. This technique is used to eliminate false data dependencies arising from the reuse of registers by successive instructions that do not have any real data dependencies between them. The elimination of these false data dependencies reveals more instruction level parallelism in an instruction stream, which can be exploited by various and complementary techniques such as superscalar and out of order execution for better performance.

Programs are composed of instructions which operate on values. The instructions must name these values in order to distinguish them from one another. A typical instruction might say: add and and put the result in In this instruction, , and are the names of storage locations. It is common for the values being manipulated to be used several times in succession. Register machines take advantage of this by introducing a number of processor registers, which are high speed memory locations that hold these values. Instructions that use the registers as intermediate values will run much faster than those that access main memory. This performance increase is a key design element of the RISC processor design, which uses registers for all of its primary math and logical instructions. The collection of registers in a particular design is known as its register file. Individual registers in the file are referred to by number in the machine code. Encoding a number in the machine code requires several bits. For instance, in the Zilog Z80 there were eight general purpose registers in the file. To select one of eight values requires three bits, as 23 = 8. More registers in the file will result in better performance, as more temporary values can be held in the file and thus avoid the expensive operations of saving or loading from memory. Generally, more modern processors and those with larger instruction words will use more registers when possible. For example, the x86 instruction set architecture has 8 general purpose registers, x86 64 has 16, many RISCs have 32, and IA 64 has 128. The advantages of a larger register file are offset by the need to use more bits to encode the register number. For instance, in a system using 32 bit instructions, you might wish to have three registers, such that you can perform operations of the type = If the register file contains 32 entries, each one of the references will require 5 bits, and the set of three registers thus takes up 15 bits, leaving 17 to encode the operation and other information. Expanding the register file to 64 entries would require 6 bits, a total of 18 bits. While this may result in faster performance, it also means there are fewer bits left over for encoding the instruction. This leads to an effort to balance the size of the file with the number of possible instructions.

This is the renaming style used in the MIPS R10000, the Alpha 21264, and in the FP section of the AMD Athlon. In the renaming stage, every architectural register referenced (for read or write) is looked up in an architecturally indexed remap file. This file returns a tag and a ready bit. The tag is non ready if there is a queued instruction which will write to it that has not yet executed. For read operands, this tag takes the place of the architectural register in the instruction. For every register write, a new tag is pulled from a free tag FIFO, and a new mapping is written into the remap file, so that future instructions reading the architectural register will refer to this new tag. The tag is marked as unready, because the instruction has not yet executed. The previous physical register allocated for that architectural register is saved with the instruction in the reorder buffer, which is a FIFO that holds the instructions in program order between the decode and graduation stages. The instructions are then placed in various issue queues. As instructions are executed, the tags for their results are broadcast, and the issue queues match these tags against the tags of their non ready source operands. A match means that the operand is ready. The remap file also matches these tags, so that it can mark the corresponding physical registers as ready. When all the operands of an instruction in an issue queue are ready, that instruction is ready to issue. The issue queues pick ready instructions to send to the various functional units each cycle. Non ready instructions stay in the issue queues. This unordered removal of instructions from the issue queues can make them large and power consuming. Issued instructions read from a tag indexed physical register file (bypassing just broadcast operands) and then execute. Execution results are written to tag indexed physical register file, as well as broadcast to the bypass network preceding each functional unit. Graduation puts the previous tag for the written architectural register into the free queue so that it can be reused for a newly decoded instruction. An exception or branch misprediction causes the remap file to back up to the remap state at last valid instruction via combination of state snapshots and cycling through the previous tags in the in order pre graduation queue. Since this mechanism is required, and since it can recover any remap state (not just the state before the instruction currently being graduated), branch mispredictions can be handled before the branch reaches graduation, potentially hiding the branch misprediction latency.

This is the style used in the integer section of the AMD K7 and K8 designs. In the renaming stage, every architectural register referenced for reads is looked up in both the architecturally indexed future file and the rename file. The future file read gives the value of that register, if there is no outstanding instruction yet to write to it (i. e., it's ready). When the instruction is placed in an issue queue, the values read from the future file are written into the corresponding entries in the reservation stations. Register writes in the instruction cause a new, non ready tag to be written into the rename file. The tag number is usually serially allocated in instruction order—no free tag FIFO is necessary. Just as with the tag indexed scheme, the issue queues wait for non ready operands to see matching tag broadcasts. Unlike the tag indexed scheme, matching tags cause the corresponding broadcast value to be written into the issue queue entry's reservation station. Issued instructions read their arguments from the reservation station, bypass just broadcast operands, and then execute. As mentioned earlier, the reservation station register files are usually small, with perhaps eight entries. Execution results are written to the reorder buffer, to the reservation stations (if the issue queue entry has a matching tag), and to the future file if this is the last instruction to target that architectural register (in which case register is marked ready). Graduation copies the value from the reorder buffer into the architectural register file. The sole use of the architectural register file is to recover from exceptions and branch mispredictions. Exceptions and branch mispredictions, recognized at graduation, cause the architectural file to be copied to the future file, and all registers marked as ready in the rename file. There is usually no way to reconstruct the state of the future file for some instruction intermediate between decode and graduation, so there is usually no way to do early recovery from branch mispredictions.

In both schemes, instructions are inserted in order into the issue queues, but are removed out of order. If the queues do not collapse empty slots, then they will either have many unused entries, or require some sort of variable priority encoding for when multiple instructions are simultaneously ready to go. Queues that collapse holes have simpler priority encoding, but require simple but large circuitry to advance instructions through the queue. Reservation stations have better latency from rename to execute, because the rename stage finds the register values directly, rather than finding the physical register number, and then using that to find the value. This latency shows up as a component of the branch misprediction latency. Reservation stations also have better latency from instruction issue to execution, because each local register file is smaller than the large central file of the tag indexed scheme. Tag generation and exception processing are also simpler in the reservation station scheme, as discussed below. The physical register files used by reservation stations usually collapse unused entries in parallel with the issue queue they serve, which makes these register files larger in aggregate, and consume more power, and more complicated than the simpler register files used in a tag indexed scheme. Worse yet, every entry in each reservation station can be written by every result bus, so that a reservation station machine with, e. g., 8 issue queue entries per functional unit will typically have 9 times as many bypass networks as an equivalent tag indexed machine. Consequently, result forwarding consumes much more power and area than in a tag indexed design. Furthermore, the reservation station scheme has four places (Future File, Reservation Station, Reorder Buffer and Architectural File) where a result value can be stored, whereas the tag indexed scheme has just one (the physical register file). Because the results from the functional units, broadcast to all these storage locations, must reach a much larger number of locations in the machine than in the tag indexed scheme, this function consumes more power, area, and time. Still, in machines equipped with very accurate branch prediction schemes and if execute latencies are a major concern, reservation stations can work remarkably well.