Editing Register renaming (section)

=== Reservation stations ===
{{Main|Reservation station}}
<!--[[Image:register renaming:reservation station scheme.png|{{deletable image-caption}}]]-->

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 [[re-order buffer|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.