the reorder buffer

Picture a deli where cooks may finish sandwiches in any order, but the wrapped sandwiches are placed onto a numbered conveyor and handed to customers strictly in ticket order. A sandwich finished early just waits its turn on the belt; nothing is given out ahead of an earlier order. The reorder buffer (ROB) is that numbered conveyor inside an out-of-order CPU: a queue that holds the results of instructions that have executed but not yet been made official, releasing them — committing them — in the original program order.

Mechanically, when an instruction is issued it is also allocated an entry at the tail of the ROB, preserving program order. Instructions then execute out of order; each writes its result into its own ROB entry and marks itself done. Commit happens only from the head of the ROB, in order: the oldest instruction, once finished, writes its result to the architectural register file or memory and frees its entry, then the next one, and so on. If an instruction at the head raised an exception, or a branch ahead of it was mispredicted, the machine discards that entry and everything younger — they never become official. Speculative work simply evaporates from the ROB without touching visible state.

The reorder buffer is what reconciles aggressive out-of-order, speculative execution with the strict requirement that the program behave as if it ran sequentially. It delivers two things at once: in-order commit (the visible state changes in program order) and precise exceptions (when a fault is reported, exactly the instructions before it have completed and none after). Without a ROB you could execute out of order, but you could not cleanly recover from mispredictions or report exceptions at the right instruction. Its size also bounds how far ahead the core can speculate.