CPU Reorder Buffer Interview: In-Order Retirement and Precise Exceptions

A reorder buffer lets instructions complete out of order while making architectural state advance in program order. A completed younger result must wait behind older unfinished work. If an older instruction faults, the machine must expose the correct earlier state and discard younger architectural effects, even when those younger operations already finished.

The original retirement ledger below makes that rule concrete. PracHub's CPU microarchitecture and simulator-design question offers broader preparation context. Here the central question is which effects may become architectural, rather than which instruction happens to finish first.

BOOM's public documentation is the implementation reference. The instructions, completion order and randomized checks are original teaching models. We did not run BOOM RTL, a complete ISA simulator or an interrupt/coherence verification suite. No candidate-report set establishes a particular employer's interview format.

Define completion, retirement and the architectural prefix

Completion means an operation has produced the result or status its execution path requires. Retirement means the machine accepts its effects into the architectural history under the ordering rules. The events answer different questions and may be separated by many cycles.

Model precise state as a sequential prefix: the visible state reflects all permitted effects before a particular instruction boundary, with none from younger instructions beyond that boundary. At a synchronous fault, older instructions can have retired, the faulting instruction does not commit its ordinary result, and younger effects must not appear as if they executed successfully.

BOOM describes an ordered ROB whose entries become nonbusy as execution finishes and commit from the head. It records exceptions and acts on the relevant exception when it reaches the head. This is one documented organization, including banked rows; our exercise uses a simpler logical instruction sequence. BOOM reorder buffer

Do not assume every ROB stores the result data itself. In an explicit physical-register design, values can reside in the physical register file while the ROB tracks status and retirement information. The architectural-visibility rule remains necessary regardless of the storage arrangement.

Trace a younger completion behind an older fault

Use four original operations in program order. I0 writes r1 = 5 and completes late. I1 is a divide that reports a fault. I2 writes r3 = 9, and I3 is a store of 7 to address A. Initially r1, r3 and memory A are zero.

Choose completion order I2, I1, I3, I0. Completion deliberately occurs out of program order. I2's early result is speculative. I1's early fault report is recorded, but older I0 still needs to establish the state before the fault boundary.

The final architectural state has r1 = 5, while r3 and memory A retain their initial zero values. I2's computed nine and I3's store payload seven do not become architectural simply because they were ready before I0.

This example excludes fault-handler execution. It stops at the precise fault boundary. A real handler's later changes are a separate architectural sequence and should not be mixed into the state used to explain the original fault.

Record a fault when discovered and raise it at the right boundary

A younger operation can discover an error before the oldest instruction completes. Recording that information early is useful, but immediately redirecting execution without preserving the required older state can produce an imprecise result.

In the example, I1's fault must not erase I0's legitimate r1 update. Conversely, allowing I2 to retire while waiting for I0 would expose a result from after the fault. The ROB's ordered retirement boundary separates both mistakes from the correct prefix.

If several instructions report faults, ask which is oldest in program order. Discovery time is not necessarily exception priority. A younger fault found first can become irrelevant if an older instruction later faults or a surviving branch redirects execution before it.

A completed instruction with no fault can still wait behind a faulting older entry. “Done” therefore needs a precise definition in a waveform or simulator log. Ready for writeback, no longer busy and architecturally committed are not interchangeable labels.

For an interview follow-up, change I0 to a load that also faults after I1 reports its divide error. The architectural boundary now lies at I0 under the stated ordering. Do not keep I1's exception merely because it was discovered first.

Make multiwide retirement stop at the first blocker

A machine that can retire several instructions per cycle still commits an ordered prefix. It cannot skip an unfinished entry in the middle and retire later entries solely because there is spare commit bandwidth. Width changes how many eligible consecutive entries can advance, not the ordering rule.

In our four-operation example with commit width two, I0 can retire when ready. I1 then blocks normal retirement because it is faulting. I2 cannot use the second slot to slip past the fault. Whether the trap action occurs in that cycle or a later control cycle is an implementation timing detail.

Similarly, if the first two entries are complete and safe while the third is busy, a wider machine can commit the first two and stop. A checker should compare the committed sequence with an eligible prefix rather than requiring the full configured width every cycle.

BOOM's implementation has row and bank constraints described in its ROB documentation. Our logical prefix model does not reproduce those physical commit restrictions. It supplies a semantic condition that any proposed implementation trace must respect, not a cycle-accurate model of that design.

Keep store authorization and store draining separate

I3's ready payload is not permission to update memory before older faults are resolved. Once a store legally commits, it may still wait in a store queue before the memory system accepts it. “Committed,” “drained locally” and “visible to another core” describe different boundaries.

BOOM's load/store documentation describes stores being marked committed before they are free to fire to the memory system. Use that interface to explain who authorizes a side effect and who performs it. Our example intentionally never authorizes I3 because I1 faults first. BOOM load/store unit

A wrong design might write memory when store data becomes ready, then try to undo it after discovering an older fault. That is not automatically safe: another observer or a device might already have seen the effect. Delaying irreversible effects until the correct boundary is central to the argument.

Memory-mapped I/O and atomics require additional constraints beyond this ordinary cacheable-store example. Do not generalize a speculative cache request into permission to perform an externally visible device action. State the operation class before discussing what can execute early.

Connect retirement to physical-register recovery

After a fault, younger speculative mappings must be discarded while committed values remain reachable. BOOM's rename documentation discusses recovery using committed state or unwinding structures, depending on configuration. That choice affects recovery latency and retained information. BOOM rename stage

In the ledger, the map after I0 retires must still identify the physical value representing r1 = 5. A broad reset to the process's initial register mapping would lose a valid older effect. Recovery must target the architectural boundary, not an arbitrary earlier snapshot.

Physical registers allocated to squashed younger instructions can be reclaimed under the allocator's rules. But late execution responses must not corrupt a register that has been reassigned. A ROB slot number or physical index alone may be insufficient if that identity can be reused before every old response disappears.

A proposed solution can use generation information, valid branch ownership or another cancellation protocol. Explain the invariant it enforces. Our retirement model does not implement these buses or allocator races, so it cannot claim to verify that integration.

Check against an independent sequential-prefix oracle

Our local Python model accepts a program and a permutation of completion events. It records completed entries, then advances only from the current head. On a fault at the head, it stops without applying that instruction or younger effects.

For the four-operation example, the checker produced only the r1 update, no memory update and retired sequence [0], with fault index one. A deliberately wrong commit-on-completion interpretation would expose r3 = 9 immediately and fail the expected architectural state.

We also generated 300 seeded cases with twenty register-writing operations, one fault at a varied position and shuffled completion order. The independent reference executed only the sequential program prefix before the fault. The modeled retirement state and retired indices agreed with that reference in every case.

This checks completion-order independence under a narrow model. It does not prove arbitrary exception behavior, multiple faults, speculative loads, asynchronous interrupts, queue wraparound or full instruction semantics. Those limits belong beside the test result so the number of random cases does not sound like a complete verification claim.

Turn a waveform into a retirement argument

When shown an out-of-order trace, first reconstruct program age, ROB head and each entry's status. Then distinguish execution completion from accepted retirement events. Numeric results appearing on a bus do not establish that the architectural state changed.

Identify the oldest blocker and ask what would remove it. An unfinished operation needs a completion or cancellation event. A faulting head needs the defined exception protocol. A ready store may need a legal commit token and downstream acceptance before later drain progress.

Finally, compare the architectural state at the boundary with a sequential reference. Check registers and stores separately. A trace that preserves register order but lets a younger store escape still violates the intended precise-state behavior.

Practice a precise-exception explanation

The following PracHub records develop microarchitecture, out-of-order behavior, verification and trace reasoning. Shared broad CPU records support different retirement-prefix follow-ups here than in the renaming article. They are practice material, not a prediction of any employer's interview questions.

Use the CPU microarchitecture question and present completion order I2, I1, I3, I0. Name the visible final values before drawing any implementation. Then explain which structure prevents each forbidden younger effect and which additional verification would be needed for late responses after a flush.

Sources and Further Reading

• BOOM: reorder-buffer state, commit and exceptions
• BOOM: rename-state recovery
• BOOM: store commitment and memory-system interaction

Sources checked November 3, 2026. Original completion-permutation checks validate a bounded retirement model, not full processor correctness.