Questions: Out-of-Order Execution and Register Renaming

Question 1

Two instructions both write to register R1 but neither reads the result of the other. A classic in-order pipeline would stall on this hazard. What does register renaming do to resolve it?

• A. It detects that R1 is shared and forces both instructions to wait for a lock on the register
• B. It assigns each instruction a distinct physical register, eliminating the false dependency entirely
• C. It reorders the instructions so the second write happens first, preventing the naming conflict
• D. It routes both writes through the reorder buffer, which serializes them at commit time

Answer: (B)

The WAW (write-after-write) hazard here is a *false dependency* — no actual data flows between the two instructions; they just happen to target the same architectural register name. Register renaming resolves this by mapping each write to a fresh physical register from a pool. The two instructions now write to different physical locations and can execute simultaneously. Only true RAW (read-after-write) dependencies — where one instruction genuinely needs another's result — remain after renaming. Options A and D describe serialization, not elimination; option C describes reordering, which does not resolve the underlying naming conflict.

Question 2

Why does out-of-order execution still require instructions to *retire* (commit to architectural state) in program order?

• A. To ensure that each instruction occupies a functional unit for the same number of cycles
• B. Because register renaming cannot correctly track results committed out of order
• C. So the processor can recover a consistent architectural state after exceptions or branch mispredictions
• D. To prevent the reorder buffer from overflowing when many instructions are in flight

Answer: (C)

If instructions committed their results to the visible architectural state as soon as they finished executing, an exception in an early instruction would find that later instructions had already modified registers and memory — making precise recovery impossible. The reorder buffer (ROB) holds completed results and releases them to architectural state strictly in program order, so the committed state always reflects what in-order execution would have produced up to that point. This invariant enables precise exception handling and recovery from branch mispredictions.

Question 3

Register renaming in out-of-order processors eliminates most data dependencies between instructions.

• T. True
• F. False

Answer: False

Register renaming eliminates only *false dependencies* — WAW (write-after-write) and WAR (write-after-read) hazards that arise purely from reuse of the same register name. It cannot eliminate true RAW (read-after-write) dependencies, where one instruction genuinely needs the result produced by an earlier instruction. Those real dependencies still enforce ordering constraints. The power of renaming is removing the artificial constraints introduced by the ISA's limited number of architectural registers, revealing the true data-flow graph.

Question 4

Instructions in an out-of-order processor may execute in a different order than they were issued, and they also retire (commit to the architectural register file) in a different order than they were issued.

• T. True
• F. False

Answer: False

Out-of-order *execution* is the entire point: instructions execute as soon as their inputs are ready, regardless of program order. But *retirement* (committing results to the visible architectural state) always happens in program order, enforced by the reorder buffer (ROB). This in-order retirement is essential for precise exception handling — the processor can always roll back to a consistent state. Conflating execution order with retirement order is a common confusion about OoO processors.

Question 5

What is the role of the reorder buffer (ROB) in an out-of-order processor, and why is it necessary?

Model answer: The ROB holds results of instructions that have finished executing but have not yet been committed to the architectural state. It ensures that despite out-of-order execution, instructions retire strictly in program order. This is necessary for precise exceptions: if an instruction causes an exception, all instructions before it in program order can be committed and all after it can be squashed, leaving a consistent state for recovery. Without the ROB, out-of-order commits would make recovery from exceptions or branch mispredictions impossible.

The ROB reconciles the performance goal (execute out of order) with the correctness requirement (maintain sequential semantics). It also enables branch misprediction recovery: the ROB can flush all instructions after the mispredicted branch, restoring the last known-good committed state. The ROB, reservation stations, and rename tables together are the core microarchitectural structures that make OoO execution work.