Reorder Buffers: How Hardware Commits Out-of-Order Instructions In the Right Order

2026-06-14

Tomasulo's algorithm lets instructions execute out of order, and register renaming kills false dependencies — but the architectural state the programmer sees must still look like instructions retired one at a time, in program order. The Reorder Buffer (ROB) is the circular FIFO that makes that illusion work.

The ROB is a hardware queue of in-flight instructions, indexed by a tag assigned at dispatch. Each entry holds: the destination physical register, the architectural register it will eventually write, the PC, an exception bit, and a "ready" bit. Dispatch pushes to the tail; commit pops from the head — but only when the head's ready bit is set.

The key invariant: results write into the physical register file as soon as execution finishes, but they only become architecturally visible at commit. A mispredicted branch or an exception ten instructions back? The ROB simply flushes everything past the offending entry, rolls the rename map back to a checkpoint, and the speculative results vanish. No software ever sees them.

Concrete example — Intel Skylake: 224-entry ROB, retires up to 4 instructions per cycle. If a load misses L2 and stalls at the head for 200 cycles, the back end can keep executing — but the ROB fills up, dispatch stalls, and IPC collapses. This is why memory latency, not compute, is usually the bottleneck on modern cores. The ROB size literally bounds how far ahead the machine can speculate.

Sizing rule of thumb: ROB entries ≈ peak IPC × worst-case latency you want to hide. For a 4-wide machine hiding a 50-cycle L2 miss, you need at least 200 entries just to keep the front end fed during the miss. That's why ROBs have ballooned from 40 entries (P6, 1995) to 600+ entries (Apple M-series, 2024).

The commit logic itself is subtle: each cycle, you scan the head N entries (commit width), AND their ready bits, and pop the longest prefix that's all ready. An exception bit on any entry blocks commit and triggers flush. Stores don't write to cache until they commit — that's what makes the memory model precise, and it's why store buffers exist downstream of the ROB.

Without a ROB, precise exceptions on an out-of-order machine are essentially impossible. Early OoO designs (CDC 6600) skipped this and had "imprecise interrupts" — the program counter on a fault was approximate. Nobody ships that anymore because debuggers and virtual memory need exact PCs.

See it in action: Check out How CPUs Keep Order: The Commit Stage Explained by CodeLucky to see this theory applied.
Key Takeaway: The reorder buffer is the bookkeeping queue that lets hardware execute wildly out of order while pretending — to software, debuggers, and the memory system — that everything happened sequentially.

All newsletters