Day 46: Control hazards: branch resolution and static prediction
Control hazards and branch handling
A control hazard arises because a branch's outcome isn't known until it's resolved (in EX, for ChipX), but the pipeline has already fetched the next instruction(s) speculatively. If the branch is taken and those fetches were wrong, they must be flushed (turned into bubbles). The number of wasted cycles is the branch penalty.
ChipX uses static branch prediction: always predict *not taken*, fetch the fall-through, and flush if the branch turns out taken. Simple and adequate for a first core. Resolving branches *earlier* (moving the comparison into ID) shrinks the penalty. Real high-end cores use dynamic prediction (history tables, gshare) — awareness only for ChipX (Day 52), implementation is v2.0.
Predict-not-taken is honest
For ChipX, always-not-taken costs a small flush penalty only on taken branches and needs zero prediction hardware. Stating that trade clearly — 'I chose static prediction; here's the penalty; here's how dynamic prediction would cut it' — is exactly the kind of engineering judgment interviewers want to hear, and it keeps the frozen scope intact.
Key terms
- Control hazard
- Uncertainty about the next PC because a branch/jump is not yet resolved.
- Flush
- Converting wrongly-fetched instructions into bubbles when a branch is mispredicted.
- Branch penalty
- The cycles lost to flushing on a misprediction; smaller if branches resolve earlier.
- Static prediction
- A fixed guess (e.g. always not-taken) needing no history hardware.
- Dynamic prediction
- History-based prediction (2-bit counters, gshare) — high-end, awareness-level for ChipX.
Before moving on, you should be able to
With predict-not-taken, when does ChipX incur a branch penalty?
