U. Glaeser

fetch engine to identify which instructions are branches or to compute branch targets. Unfortunately, in
most programs more than half of branches are taken [17], making the performance of static-not-taken
usually quite poor. On the other hand, a static taken policy either requires the fetch engine to identify
which instructions are branches and immediately identify their taken targets, or requires some delay
while instructions are decoded and the target is computed.
A third policy takes advantage of the fact that backward conditional branches almost always correspond
to loops, which tend to iterate multiple times, so these branches are likely to be taken. Non-backward branches,
on the other hand, are less biased. Hennessy and Patterson [10] found that 85% of backward branches are
taken while only 60% of forward branches are taken. This suggests a static policy of backwards-taken,
forwards-not-taken, or BTFNT. The problem of computing branch targets remains.
These policies were described by Smith [17] along with the core, bimodal dynamic prediction technique
described in the section on “Bimodal Prediction.” Another seminal paper from this era is the exploration
of branch predictor and branch target address cache design choices by Lee and Smith [18]. Both papers
also survey the earliest literature on branch handling.
Branch Target Address Caches
Not only static techniques, but in fact all branch-prediction techniques have the problem that on a
predicted-taken branch, the branch’s target must be computed. This requires extracting the offset field
from the branch instruction and adding it to the PC; tasks which typically cannot be performed until
the instruction-decode stage. If this is the case, some stall cycles result, called a “branch-taken bubble.”
A second type of predictor—a branch target predictor—can eliminate this problem. In its simplest form,
this is simply a small on-chip memory in the fetch stage that serves as a table of recently seen branches,
a branch target address cache or BTAC [19,20]. (The BTAC is also often referred to as a branch target
buffer or BTB, but this latter term is too heavily overloaded.) The BTAC is indexed with the branch’s
address (in other words, the PC—program counter—used to fetch the branch). It may be direct-mapped
or associative, and tagged or not tagged. Omitting tags reduces cost, but then a BTAC miss cannot be
identified, the predicted-taken branch will use the wrong target, and this will not be discovered until the
branch resolves. For this reason, BTACs are best tagged.
The dynamic hardware schemes described later in this section maintain tables in which they track
state about conditional branch directions. These direction-prediction tables are often indexed using the
branch address. Because the BTAC table is also indexed by branch address, it may be convenient with
these dynamic schemes to store the direction-prediction information in the BTAC along with each
branch’s target. Aside from the convenience of integrating these different sources of information into
one table, this confers the advantage that if the BTAC is tagged, any branch prediction state stored in the
BTAC is also tagged. While some processors use this organization, Calder and Grunwald [21] point out
that many branches are not taken and hence do not require the BTAC to store a target. Decoupling the
direction-prediction state from the target-prediction state therefore permits a smaller BTAC. It also
improves flexibility, as some predictors, such as global-history predictors (see the section on “Two-level
Prediction”) do not keep a one-to-one mapping between branch addresses and direction-prediction entries.
Instead of a BTAC, the processor might employ a branch target instruction cache, which stores some
actual instructions from the branch target rather than merely the target address. This replicates quite a
bit of state from the instruction cache, so this organization is rarely seen, although it does appear in the
Motorola® 5 PowerPC® 6 G4 [22], for example.
The BTAC can also be integrated with the instruction cache. Each cache line can simply store the target
address of one or more of its branches in case that branch is predicted taken. Alternatively, the I-cache
can implement a next-line predictor [23]. Each cache line now stores the index of the next cache line to
be fetched (and also the set if the cache is associative) [24]. If no branches are taken in the current line,
the next-line address will be the next sequential address. If there is a taken branch, the next-line address
5 Motorola, Inc., Schaumburg, Illinois.
6 International Business Machines Corp., Armonk, New York.
© 2002 by CRC Press LLC