MB>
  > MB>
  >   > From a machine level point of view, you want branches to be not taken
  >   > more frequently than taken.  This is because taking a branch
  >   > always flushes the prefetch instruction queue in the Intel
  >   > processors, [...]
  > MB>
  >
  > JdeBP>   With speculative execution and branch prediction in
  > JdeBP> processors like the Pentium Pro, or the Cyrix 5x86 and 6x86,
  > JdeBP> I don't believe that this is as true as it used to be.
  >
  > The Cyrix 5x86 does not do any speculative execution [...]
MB>

The Cyrix 6x86 does both.  The Cyrix 5x86 does branch prediction.  Which
is what I implied.

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

No.

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

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

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

In the more complex world of the Cyrix 5x86/6x86 and Pentium Pro, it is
the case that the most efficient arrangement is to code so that the most
commonly taken path matches the guess that the branch prediction heuristic
will make.

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

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01