Precise exceptions: finishing is not committing

A common out-of-order design keeps records of in-flight instructions in program order. Execution can finish younger ready work before an older stalled operation, but retirement advances from the oldest eligible instruction. If an older ordinary load faults, younger computed register results must not survive as committed program results. The exception handler sees a state corresponding to a precise architectural boundary, rather than an arbitrary mixture determined by execution-unit completion times. The exact saved instruction address follows the fault’s documented architectural rules.

An exception discovered during execution can therefore be recorded and handled when the instruction reaches the retirement boundary. This also prevents a fault on a discarded wrong path from behaving like a committed faulting instruction. Do not generalize the teaching model to every interrupt, trap, machine check, or partially completing instruction. Architecture manuals distinguish exception categories and specify restart behavior. The key mechanism is enough bookkeeping to decide which results belong to the accepted path and which must be discarded.

A store may calculate its address and data before retirement, then wait in structures that preserve ordering and permit recovery. Committing the instruction does not necessarily mean its bytes are already globally visible to every other core. Store buffering, coherence, and the architecture’s memory-order rules determine the visibility story. Likewise, retiring a load does not mean every cache or translation structure has returned to its prior state. Distinguish committed architectural values from internal state changes when discussing speculation.

A precise exception is therefore a functional state guarantee, not a promise that speculative work left no measurable trace. A cache line fetched on a wrong path can affect later access time even though the corresponding instruction did not retire. Side-channel defenses require their own documented mechanisms and threat model. Separately, persistence to nonvolatile media is another milestone beyond ordinary store visibility. Using the word committed without specifying the layer can accidentally collapse CPU retirement, inter-core communication, and durable storage into one false guarantee.

For a short trace, list instructions in program order and separately mark operand readiness, execution completion, detected faults, and retirement. When the head cannot retire, a younger completed result does not authorize jumping the boundary. On a fault, remove younger speculative results from the architectural continuation according to the documented rules. A debugging register dump then becomes understandable: it describes an accepted boundary, not a photograph of every physical register and cache transaction inside the machine.

The queue lab has four units of initial backlog and arrivals and service controlled by λ and μ. Use it to predict how a backlog changes when admission outruns service, as an analogy for a finite in-flight window waiting behind a bottleneck. It does not contain instructions, faults, or a reorder buffer. In particular, its fluid service rule does not implement ordered retirement. Keep the actual fault trace on paper so the analogy cannot replace the mechanism that makes precise recovery possible.