I do not understand how BTP differs from BP? Yes I understand BP evaluates whether a conditional is true/false, but surely implicitly this also determines the "target" instruction?

If I predict the first branch of an IF to be true, then surely I have just determined the branch target too (the code within the predicted IF branch)??

  • 1
    From en.wikipedia.org/wiki/Branch_predictor: Branch prediction is not the same as branch target prediction. Branch prediction attempts to guess whether a conditional jump will be taken or not. Branch target prediction attempts to guess the target of a taken conditional or unconditional jump before it is computed by decoding and executing the instruction itself. Branch prediction and branch target prediction are often combined into the same circuitry. – Robert Harvey Feb 14 '14 at 21:06
  • I have read that- my question says that if you predict the branch conditional havent you also predicted the branch target? – user997112 Feb 14 '14 at 22:00
  • 4
    Well, I'm not an expert on this, but it seems to me that the decision to jump and where to jump are two different things. Where to jump is not inconsequential; it has to do with (among other things) cache locality, the expense of the branch in terms of computational complexity and execution time, etc. Branch prediction is concerned only with "to branch, or not to branch" (i.e. the statistical probability of one branch executing over another), and not with the cost of a particular branch. – Robert Harvey Feb 14 '14 at 22:27
  • A BP table will also be roughly half the size of a BTP table. Both need to record the address of the jump, but the BTP also needs the target location instead of a bit for jump/no jump. – user22815 May 6 '14 at 18:58

Consider the following loop in assembly:

loop: ADDI R1, R1, #-1 ;subtract 1 from the value stored in R1
      BNEZ R1, loop ; if the value of R1 is not 0, go to the code at label "loop"

      SUBI R2, R2, #2 ; completely unrelated to the loop

This code will continuously subtract 1 from the value stored in R1, until the value in R1 is 0. Pretty simple, if not practical. Equivalent C code might read

while(a != 0)

According to Wikipedia:

In computer architecture, a branch predictor is a digital circuit that tries to guess which way a branch (e.g. an if-then-else structure) will go before this is known for sure.

In this example, the branch predictor will try to guess if the value of R1 is, in fact, 0, by various methods covered in the Wikipedia article. All the branch predictor does is determine "Yes, this branch is going to be taken", or "No, this branch will not be taken."

On the other hand, a Branch Target Predictor will take the results of the Branch Predictor, and give the address that the program is going to jump to.

Using the example above, if the branch predictor says that the BNEZ instruction is going to take the branch, the branch target predictor will give the Address of the next instruction to execute after the ADDI instruction. This might be the ADDI instruction, at the label loop, or it might be the SUBI instruction after the the branch instruction.

The Branch Predictor predicts the result of a comparison. The Branch Target Predictor give where the program is going because of a branch.

Branches (and jumps, for that matter), are Program Counter (PC) relative. The Branch Target Predictor will add the offset (given by the branch instruction), and add it to the current program counter. This gives the address of the instruction to execute after the branch.

Branch Predictors give a Yes/No answer to the question "Am I going to branch". The Branch Target Predictor needs that Yes/No answer to determine the answer to "WHERE am I going after the branch".

  • But in this example there is indeed no "prediction" for BTP to do, as the target is deterministic. So I think an indirect jump (as given by Peter) is a better illustration for the difference. – qweruiop Mar 30 '17 at 19:51

Indirect jumps / calls (through a function pointer or a switch using a jump table) don't have the branch target available when an instruction is decoded. Even without a cache miss or something, jmp rax has to fetch the value of rax from the register file (or forwarding network). The Branch Target Buffer predicts the target address way ahead of this, so code fetch can start ASAP. A sophisticated BTB can recognize patterns, like an indirect jump that alternates between two targets. Good BTB performance is critical for indirect jumps. (Combined with the usual need for good normal branch prediction (taken vs. not-taken) for conditional indirect branches).

A BTB can also predict where a jump is going before the jmp instruction is even decoded. This is important on an architecture like x86, where the variable-length instruction encoding makes it impossible to scan the instruction stream for upcoming branches ahead of what's currently being decoded. There are multiple fetch / pre-decode pipeline stages ahead of the point where a jmp is fully decoded.

See this SO question for an example of the BTB speeding up normal unconditional direct jmp instructions on an Intel Broadwell. A loop with much less than 4096 jmps runs at 1 jmp per ~3 cycles, while a large loop (with many more jmps than the BTB can hold) runs slower, like 1 jmp per ~12 cycles.

  • Another case is a "return" instruction, where you would have to read the return address from the stack. But a good guess for the return address is "just after the call instruction". – gnasher729 Feb 27 '17 at 23:25
  • @gnasher729: yes, ret is a special case of an indirect branch. But how do you know the address of the call instruction? Especially for functions with multiple callers, it's non-trivial. The usual solution is a small return-address predictor stack, which is why mismatched call/ret instructions are bad for performance. – Peter Cordes Mar 1 '17 at 12:40
  • This example best illustrates the difference among other answers. – qweruiop Mar 30 '17 at 19:52

Put simply:

Branch Prediction predicts the answer to "Will I branch?"

Branch Target Prediction predicts the answer to "Where will I branch to?"

Both of these are considered at the same time. An optimal CPU will be able to not only predict wether or not a branch will happen, but also where it will branch to. This would allow it to start pushing instructions through the pipeline that it predicts will be coming up.

protected by gnat Aug 8 '16 at 21:40

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.