Dynamic scheduling · speculation
Separate execution order from architectural order.
An out-of-order core looks ahead, renames values, and schedules ready work. In-order retirement preserves precise per-thread architectural state; the ISA memory model separately constrains which memory orders other cores may observe.
Instruction lifecycle explorer
Execute when ready. Retire when safe.
Front end
Build an ordered stream.
The fetch engine predicts the next PC, fetches a block, and decodes instructions in program order. A wide front end can produce several operations per cycle, but it still needs accurate direction and target predictions to remain fed.
Live reorder-buffer snapshot
Completion can pass; architectural visibility cannot.
LD p21 ← [p4]Oldest · L1 missDecodedSpeculativeADD p22 ← p21, p7True RAW on I0Front-end queueSpeculativeMUL p31 ← p8, p9IndependentFront-end queueSpeculativeXOR p32 ← p10, p11IndependentFront-end queueSpeculativeLifecycle state update. Step 1, Fetch + decode. The front end knows program order, but the ROB has not exposed any result to architectural state.
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 page fault is recorded speculatively. 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 cannot update committed memory state. After retirement, a committed store may wait in a store buffer before becoming visible to other cores, subject to the ISA memory model.
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.
Put it into practice
Explain the mechanism. Test your reasoning.
Use the experiment above to support your answer, then apply the idea in the question bank.
- Reference Models · HardRetire out-of-order completions in orderPractice →
- Hardware Algorithms · MediumValidate micro-operation dependenciesPractice →
Continue the learning path
Next: Branch prediction
Simulate saturating counters and global history, distinguish BHT direction from BTB targets, and account for bubbles even when direction is correct.