Jonathan de Boyne Pollard wrote in a message to Mike Bilow:

MB>
  > In all cases, a branch taken flushes the pipeline.
MB>

 JdBP> No.

I was slightly too definitive in my statement, but the point is the same.

 JdBP> It obviously doesn't flush the pipeline if it contains the
 JdBP> instructions for the target of the branch.  That is, after
 JdBP> all, what branch prediction is all about.

 JdBP> The Cyrix branch prediction logic uses a heuristic to guess
 JdBP> whether to fill the pre-fetch queue with instructions from
 JdBP> the straight-line execution path or from the branch target. 
 JdBP> It can get it wrong either way. It can pre-fetch from the
 JdBP> branch target, and the branch ends up not being taken, or it
 JdBP> can pre-fetch from the straight-line path, and the branch
 JdBP> ends up being taken.

The only case in which a branch taken will not flush the pipeline when
branch prediction is in effect is if the branch target itself happens to be
in the pipeline.  This is a pure address separation heuristic, and is in
the nature of a special case.  For example:

         and   eax, 55AAh
         cmp   eax, 0
         je    mainline
         inc   eax
   mainline:

Because the "inc eax" instruction is smaller than the pipeline,
the target of the branch when taken will have already been loaded.  This is
a significant optimization, since many branches are as short as this in
practice.  However, there is very little sophistication to this kind of
thing.

 JdBP> In either event, a wrong guess results in a queue flush, and
 JdBP> a correct guess does not.  So it's not the case that "branch
 JdBP> not taken" will never result in a pipeline flush and "branch
 JdBP> taken" will always do so.  That's the simple world of the
 JdBP> Pentium and 486.

Cyrix has not been quite as straightforward about this as they might have
been, although I attribute it to bad documentation rather than intent to
deceive.  Except in the special case I discuss, a branch taken will cause a
pipeline flush.  Cyrix did eventually put out a "White Paper" on
this.

 JdBP> With all of these complexities in the new CPU architectures
 JdBP> it is, IMO, getting to the stage where hand-optimised
 JdBP> assembly language code is exceedingly unlikely to be as
 JdBP> efficient as machine-optimised code, simply because a human
 JdBP> won't be aware of the issues involved, or won't be able to
 JdBP> manually and reliably perform the steps necessary to
 JdBP> determine the optimal code sequences.

I agree with this, and I also think we will soon start to see #pragma
definitions intended to tell the compiler what we mean to do.
 
-- Mike


---