Hardware Reference
In-Depth Information
2. The number of scoreboard entries —This determines how far ahead the
pipeline can look for independent instructions. The set of instructions ex-
amined as candidates for potential execution is called the window . The size
of the scoreboard determines the size of the window. In this section, we as-
sume a window does not extend beyond a branch, so the window (and the
scoreboard) always contains straight-line code from a single basic block.
Chapter 3 shows how the window can be extended beyond a branch.
3. The number and types of functional units —This determines the importance of
structural hazards, which can increase when dynamic scheduling is used.
4. The presence of antidependences and output dependences —These lead to WAR
and WAW stalls.
Chapter 3 focuses on techniques that atack the problem of exposing and bet-
ter utilizing available instruction-level parallelism (ILP). The second and third
factors can be atacked by increasing the size of the scoreboard and the number
of functional units; however, these changes have cost implications and may also
affect cycle time. WAW and WAR hazards become more important in dynam-
ically scheduled processors because the pipeline exposes more name depend-
ences. WAW hazards also become more important if we use dynamic schedul-
ing with a branch-prediction scheme that allows multiple iterations of a loop to
overlap.
C.8 Fallacies and Pitfalls
Pitfall Unexpected Execution Sequences May Cause Unexpected Hazards.
At first glance, WAW hazards look like they should never occur in a code sequence because
no compiler would ever generate two writes to the same register without an intervening read,
but they can occur when the sequence is unexpected. For example, the first write might be in
the delay slot of a taken branch when the scheduler thought the branch would not be taken.
Here is the code sequence that could cause this:
BNEZ
R1,foo
DIV.D
F0,F2,F4; moved into delay slot
;from fall through
.....
.....
foo: L.D F0,qrs
If the branch is taken, then before the DIV.D can complete, the L.D will reach WB, causing a
WAW hazard. The hardware must detect this and may stall the issue of the L.D . Another way
this can happen is if the second write is in a trap routine. This occurs when an instruction that
traps and is writing results continues and completes after an instruction that writes the same
register in the trap handler. The hardware must detect and prevent this as well.
 
Search WWH ::




Custom Search