Pipelining: Basic and Intermediate Concepts - Computer Architecture: A Quantitative Approach - page 636

FIGURE C.10 In the top half, we can see why a stall is needed: The MEM cycle of the
load produces a value that is needed in the EX cycle of the DSUB , which occurs at the
same time . This problem is solved by inserting a stall, as shown in the bottom half.
Branch Hazards
Control hazards can cause a greater performance loss for our MIPS pipeline than do data haz-
ards. When a branch is executed, it may or may not change the PC to something other than its
current value plus 4. Recall that if a branch changes the PC to its target address, it is a taken
branch; if it falls through, it is not taken , or untaken . If instruction i is a taken branch, then the
PC is normally not changed until the end of ID, after the completion of the address calculation
and comparison.
Figure C.11 shows that the simplest method of dealing with branches is to redo the fetch of
the instruction following a branch, once we detect the branch during ID (when instructions are
decoded). The first IF cycle is essentially a stall, because it never performs useful work. You
may have noticed that if the branch is untaken, then the repetition of the IF stage is unneces-
sary since the correct instruction was indeed fetched. We will develop several schemes to take
advantage of this fact shortly.
FIGURE C.11 A branch causes a one-cycle stall in the five-stage pipeline . The instruc-
tion after the branch is fetched, but the instruction is ignored, and the fetch is restarted once
the branch target is known. It is probably obvious that if the branch is not taken, the second IF
for branch successor is redundant. This will be addressed shortly.
One stall cycle for every branch will yield a performance loss of 10% to 30% depending on
the branch frequency, so we will examine some techniques to deal with this loss.