Dynamic scheduling · speculation
Separate execution order from architectural order.
An out-of-order core looks ahead, renames values, schedules ready work, and then uses the reorder buffer to make the result look exactly like sequential execution.
Instruction lifecycle explorer
Execute when ready. Retire when safe.
Execution units · LSQ
Produce values and wake consumers.
ALUs, vector units, and the load-store unit finish at different times. Result tags wake dependent instructions. Loads consult the load-store queue before bypassing older stores whose addresses or data may still be unresolved.
Live reorder-buffer snapshot
Completion can pass; architectural visibility cannot.
LD p21 ← [p4]Oldest · L1 missL1 missSpeculativeADD p22 ← p21, p7True RAW on I0Waiting on p21SpeculativeMUL p31 ← p8, p9IndependentCompleteSpeculativeXOR p32 ← p10, p11IndependentCompleteSpeculative- I2
- I3
Lifecycle state update. Step 4, Execute + wake. I2 and I3 have completed out of order, but neither may cross the architectural boundary before I0 and I1.
Predict + fetch
- Branch predictor + BTB
- Instruction prefetcher
- I-cache and fetch queue
- Decode block
Rename + dispatch
- Speculative map table
- Physical-register free list
- ROB allocation
- Reservation stations
Schedule + execute
- Issue / wakeup logic
- ALU and branch units
- Load-store queue
- D-cache, MSHRs, memory controller / DRAM
Complete + retire
- PRF result writeback
- ROB completion state
- Store queue release
- Architectural map update
Value pathExecution broadcasts result tags through a CDB-like wakeup network; consumers read the physical value when ready.
Memory pathLoads and stores pass through ordering checks, D-cache misses allocate MSHRs, and the memory controller services the remaining request.
Recovery pathA ROB or branch checkpoint restores the rename map and free-list state, then redirects fetch while older instructions remain intact.
load p21 ← [p4]
add p22 ← p21, p7The add needs the value produced by the load. Renaming cannot invent that value, so the add waits.
read old x5 as p12
write new x5 as p37The reader keeps p12 while the new writer receives p37. Both may proceed without clobbering a name.
write x8 as p41
write x8 as p52Each destination gets a different physical register. In-order retirement chooses the architecturally latest value.
Why width stops scaling
More lanes multiply communication before they multiply performance.
Associative issue logic grows with queue entries, source operands, and simultaneous result tags.
Extra read and write ports increase array area, access energy, wiring, and often latency.
Producer-to-consumer links and muxes expand rapidly as issue width and unit count rise.
A wider window raises useful throughput only when prediction, caches, and available ILP keep it occupied.
Record now. Deliver at the ROB head.
A wrong-path divide-by-zero or page fault is only a speculative status bit. If an older branch later mispredicts, the core squashes that ROB entry. If the faulting instruction becomes oldest, the core commits all older work, blocks younger retirement, restores the proper map, and vectors to the handler.
Predict independence, then verify addresses.
The load-store queue compares a load against older stores with known addresses. An unresolved store may force the load to wait or may be bypassed using a dependence predictor. If addresses later match, the core replays the load and its dependent instructions from the correct value.
A deeper window needs more value storage.
A deeper pipeline generally keeps more instructions and destinations in flight. The PRF, ROB, issue queues, and checkpoints must grow to avoid rename stalls. Larger multiported arrays consume area, leakage and dynamic power, and can themselves become timing-critical.
Recovery + retirement
Recover speculation at a checkpoint. Report faults at the commit boundary.
Branch recovery and precise exceptions discard younger work for different reasons, but both rely on age ordering in the ROB.
- 1CheckpointSave the rename map and allocation state at a speculative branch.
- 2DetectResolve the branch, memory ordering, or exception condition.
- 3Squash youngerCancel only instructions newer than the recovery point.
- 4Restore + redirectReclaim physical registers and restart fetch from the correct PC.
- 5Retire oldestCommit completed work in order; deliver a fault only when it reaches the head.
Register invariant: the architectural map changes only in retirement order.
Store invariant: a speculative store waits in the store queue until it is safe to become externally visible.
Fault invariant: all older instructions appear complete and no younger instruction appears complete.
Why does the processor need a reorder buffer?
The ROB tracks instructions in original program order while execution finishes in another order. It records completion, faults, branch recovery state, and the point at which each result may become architectural. In-order retirement through the ROB is what provides precise exceptions and controlled recovery.
How can a load pass an older store with an unresolved address?
Conservative cores wait. Aggressive cores predict that the addresses will not alias, issue the load, and retain enough load-store-queue state to check once the store address resolves. A discovered conflict causes replay of the load and dependent work. Forwarding is used instead when an older matching store already has its data.