This page assumes you have seen the parent note Control hazards and pipeline flushes use words like stage, PC, bubble, branch, EX, saturating counter. Below we build every one of those symbols from nothing, in an order where each idea rests only on the ones before it.
Picture a tall locker wall. Each locker has a number painted on it, and inside is one command. In the parent note you saw labels like 100:, 104:, 108:. Those numbers are addresses.
Why the numbers jump by 4. Each instruction is 4 bytes wide (a common RISC choice), and memory is counted in bytes. So the locker after address 100 is 104, not 101. Whenever the parent writes PC+4, it means "the very next instruction, right below this one".
Branch taken: PC←branch target (jump the finger somewhere else).
The arrow ← just means "gets replaced by". We need the PC because the machine must always have an address ready before it can grab the next command — and that "before" is the root of every control hazard.
Why chop it up? One instruction takes 5 short steps instead of one long step. While instruction A is in EX, instruction B can be in ID, and instruction C in IF — three instructions in flight at once. This overlap is exactly why we start fetching before we know a branch's answer.
Why EX is the villain here. In this classic layout the branch's yes/no answer isn't known until EX — the third stage. By then two younger instructions have already crawled into IF and ID.
Recall Why is overlapping stages what
causes control hazards?
Because IF for the next instruction happens two ticks before EX resolves the branch — so we must fetch on a guess. ::: Overlap forces us to fetch before the branch outcome is known.
That is why the parent draws a table with cycles as columns and stages as rows (IF/ID/EX/MEM/WB). Reading it: each instruction marches diagonally down-right, one stage per tick.
Trace the amber diagonal: BEQ is in IF at cycle 1, ID at cycle 2, EX at cycle 3 — that's the cycle it finally knows the answer. Meanwhile ADD and SUB entered behind it. If the branch is taken, those two are on the wrong path.
The collection of all registers + all memory is the architectural state — the official visible result of the program. The golden rule of flushing: a wrong-path instruction must be prevented from touching architectural state.
Picture a clear gap sliding down the assembly line where a real product should be. The line stays in step (never desynchronised) but nothing is built at that slot.
Why subtract? Every stage the branch travels past IF is one extra younger instruction that has been let in behind it. Resolve one stage earlier (in ID) and you flush only 2−1=1.
We read the two-bit value as: 11 Strongly-Taken, 10 Weakly-Taken, 01 Weakly-Not-Taken, 00 Strongly-Not-Taken. "Saturating" means it can't count below 00 or above 11 — it sticks at the ends. This one idea is deepened in Branch prediction techniques.
