Follow an Instruction
`ADD R1, R2, R3` — one cycle in the textbook, a small logistics operation in a real core. Renamed, queued, executed when its inputs arrive, and only allowed to become real in program order.
One instruction: ADD R1, R2, R3. In the textbook model it takes a cycle. In a real out-of-order core it is a small logistics operation — renamed, queued, executed whenever its inputs are ready, and only allowed to become real in program order.
What happens between the program counter pointing at this instruction and its result becoming architecturally visible.
The front end reads a block of instruction bytes at the program counter, from the instruction cache. The predictor has already guessed where to fetch from next.
if it misses An instruction-cache miss starves the whole back end — no work at all is available to issue.
Bytes become an operation, source registers and a destination. On variable-length ISAs finding the boundaries is itself work.
Architectural R1 becomes a fresh physical register. This is what removes the false dependency on whatever used R1 before, and it is why the machine has far more registers than the ISA exposes.
The instruction waits in a queue until its operands are ready and a suitable execution port is free. Program order stops mattering here.
An ALU computes the sum. Integer add is among the cheapest operations a CPU has — a divide can cost tens of times more.
if it misses If an operand comes from a load that missed, this instruction sits in the queue while independent work around it proceeds. That overlap is the entire point of out-of-order execution.
The result goes to the physical register and is forwarded straight to any waiting consumer, without a round trip through the register file.
The reorder buffer commits it in program order, making it architecturally visible. Execution can be out of order; becoming real cannot.
if it misses If an older instruction faults or a branch ahead of it mispredicted, this instruction is discarded here having cost real energy and no result.