U. Glaeser

is that mispredictions limit the processor’s ability to build up a large window of instructions over which
to expose ILP.
With the misprediction penalty so high in terms of wasted instruction-issue opportunities, not only
is branch prediction necessary, but the highest possible prediction accuracy is necessary in order to
minimize stall cycles and maximize the processor’s ability to exploit ILP.
Software Techniques
Branches can be predicted or otherwise managed by both software and hardware techniques. This section
focuses on software techniques, and the section on “Hardware Techniques” focuses on hardware techniques.
Branch Delay Slots
One early software technique that was able to eliminate the need for prediction in early processors is the
branch delay slot. Instead of predicting the branch’s outcome, the instruction-set architecture can be
defined so that some number of instructions following a branch execute regardless of the branch’s
outcome. These instruction positions are called delay slot(s) and must be filled with instructions that
are safe to execute regardless of the outcome of the branch, or with nops (but nops do no useful work).
Instructions to fill the delay slot might come from positions that preceded the branch in the original
code schedule but can safely be reordered, for example. Consider the sequence of code:
1. add r1, r2, r3
2. add r4, r5, r6
3. bnez r6
4. (delay slot)
Instruction 1 can safely be moved into the delay slot, because doing so violates no data dependencies.
Instruction 2, of course, cannot be moved into the delay slot, because it computes the value of r6 that
the branch then examines. More aggressive techniques can analyze instructions from after the branch,
identify a safe instruction, and hoist it into the delay slot. A more thorough treatment of branch delay
slots and associated techniques can be found in [10].
Unfortunately, delay slots have drawbacks. Even the most aggressive techniques still leave some delay
slots unfilled, wasting instruction-issue opportunities. Delay slots also have the problem that they expose
processor implementation details that might change. Current instruction sets that use delay slots were
defined when processors issued instructions in order, one at a time, and pipelines were short. The branch
resolution delay was hence just one cycle and the corresponding penalty was only one instruction issue slot,
so these instruction sets defined branches to have a single delay slot. Examples include the MIPS® 3 [11]
and SPARC® 4 [12] instruction sets. Yet, later implementations made the pipeline longer and issued
multiple instructions per cycle. This meant that the resolution delay corresponded to many issue slots,
even though the number of delay slots was still fixed by the instruction set at one instruction. In addition,
with multiple issue, a bundle of instructions being considered for issue in any particular cycle might
consist of several instructions following a branch. Exactly one of these—the delay slot—must be issued
unconditionally, while the others are control-dependent on the branch and their execution depends on
the branch outcome. For these reasons, later instruction sets like Alpha AXP [13] do not include delay
slots.
Profiling and Compiler Annotation
An alternative software technique is to profile the program’s behavior by gathering data about how
individual branches behave. This involves gathering data while the program is running about its branches’
behavior. This data can then be fed to a second compilation pass, which annotates the branches to indicate
3 MIPS Technologies, Mountainview, California.
4 SPARC International, Inc., Santa Clara, California.
© 2002 by CRC Press LLC