|Re: Branch prediction email@example.com (2000-05-20)|
|Re: Branch prediction firstname.lastname@example.org (2000-05-21)|
|Re: Branch prediction email@example.com (2000-05-21)|
|Re: Branch prediction firstname.lastname@example.org (Andi Kleen) (2000-05-21)|
|Re: Branch prediction email@example.com (2000-05-28)|
|Re: Branch prediction firstname.lastname@example.org (2000-05-31)|
|Re: Branch prediction email@example.com (2000-06-03)|
|Re: Branch prediction firstname.lastname@example.org (2000-06-20)|
|From:||Andi Kleen <email@example.com>|
|Date:||21 May 2000 22:28:29 -0400|
|Organization:||SuSE GmbH, Nuernberg, Germany|
> >There are two sides to the branch prediction story: static
> >(compile-time) prediction and dynamic prediction done by the
> The x86 does not allow AFAIK static prediction. The PPC does.
Actually it does -- implicitely through block ordering. For example
most x86 are documented as always assuming backward branches as
taken. Modern compilers do block reordering to handle that if
necessary. Of course the reordering gets ugly pretty quickly, but it
allows at least some control for critical paths.
> There's a fundamental problem with every branch prediction system I
> ran over. They do not work with indirect jump. Most processors
> remember where the last jump landed, which might be decent for a lexer
> but absolutely impractical for a bytecode interpreter; the solution
> might be to tell the processor "hey, trust me, the jump is going to
> land there" with a special instruction.
A lot of architectures (like IIRC the PPC and IA64) use special branch
registers to solve that problem. You load the target address into a
jump register early and a sufficiently wide implementation could start
Return to the
Search the comp.compilers archives again.