Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 80 of 9361. Foundations of Digital Logic and Computer ArchitectureFree lesson

Managing Control Hazards from Branch Instructions

Quantify the performance penalty incurred when the pipeline must flush instructions following an unresolved branch or jump.

Managing Control Hazards from Branch Instructions

In this lesson, you will learn how to quantify the performance penalty—measured in "stalled cycles"—that occurs when a processor pipeline must discard instructions following an unresolved branch.

The Challenge of Speculation

In a pipelined processor, we fetch a new instruction every single clock cycle. When the processor encounters a branch instruction (like an if statement in C), it doesn't immediately know the outcome. Because the processor needs to keep the pipeline full to maximize throughput, it "guesses" which path to take (typically the next sequential instruction) while the branch logic works to determine the real target address.

Quantifying the Penalty

A Control Hazard occurs when the processor’s guess is wrong. If the branch logic determines at the end of the execution stage that the program should have jumped elsewhere, all the instructions currently "in flight" behind the branch are incorrect. They must be purged, or "flushed," from the pipeline.

Consider this assembly sequence:

1. ADD R1, R2, R3    ; Instruction A
2. BEQ R4, R5, Label ; Branch Instruction
3. SUB R6, R7, R8    ; Instruction B (Wrong path)
4. OR  R9, R10, R11  ; Instruction C (Wrong path)

If the pipeline has 5 stages (Fetch, Decode, Execute, Memory, Write-back) and the branch outcome is only decided at the end of the Execute stage, the processor will have already fetched Instructions B and C.

If the branch is taken, those two instructions must be cleared from the pipeline registers and replaced with a NOP (No Operation). This results in a 2-cycle penalty. The performance impact is calculated as:

Penalty = (Number of stages before branch resolution) - 1

Each flushed instruction represents wasted work that reduces your total instructions-per-second. If branches appear frequently in your code, these flushes create a significant drag on the processor's efficiency, essentially forcing the pipeline to "restart" its momentum. By understanding this math, we can see why minimizing the time taken to resolve branches is critical for high-speed hardware design.

Key Takeaway: A control hazard forces the pipeline to discard incorrectly fetched instructions, creating a performance penalty equal to the number of clock cycles between the branch fetch and the final branch resolution.