In a message dated 02-17-97, Jonathan de Boyne Pollard said to Mike Bilow
about Optimisation

Hi Jonathan,

MB> [...]
  >          and   eax, 55AAh
  >          cmp   eax, 0
  >          je    mainline
  >          inc   eax
  >    mainline:
MB>

[snip]

JP>In the example above, if the heuristic guesses that the branch will be
JP>taken branch prediction causes the instruction at `mainline:' to be the
JP>next instruction fetched after the JE.  The INC EAX is _not_ fetched.

This heuristic selection mechanism brings up, once more, the issue of
compiler generated code v. hand-written assembler.

It is virtually impossible to produce a CPU that will know beforehand which
path is the more likely to be taken, and it would be extremely difficult to
produce a compiler that could infer the same. OTOH, a programmer who
understands the underlying real world problem being addressed by the code
_should_ be able to offer a balance of probability that favours one path or
the other, and optimise the code correspondingly. Therefore, I would opine
that compiler generated code will still be inferior until some means of
communicating such inferences to the compiler is available.

This has been the mainframe experience too. Branch prediction has been in
place on mainframes for many years, and modern compilers still produce
object code measurably worse than well written assembler. The only problem
is finding enough skillful assembler programmers. [There are plenty of
wankers for hire, though.]

This, in turn, raises the issue of assembler programming skills. It adds the
requirement of understanding the branch prediction algorithm in the CPU's
microcode. Clearly, such knowledge is necessary to be able to optimise the
code -- you have to know how to code so that the prediction algorithm gets
it right most of the time. This also makes the resulting object code optimal
only on those models of CPU that use a branch prediction algorithm
compatible with the assumptions made during code optimisation. This could
lead to programs being offered in "Intel optimised", "Cyrix
optimised" and
"AMD optimised" variants. [And pigs might fly ...]

Overall, until we see languages with constructs such as the "assume"
directive of ECL (a language in academia in the early 1970's that was too
sophisticated for its time) compilers will remain quite a way behind the
true hacker.

Regards

Dave

___
 * MR/2 2.25 #353 * Liberace was great on the piano, but sucked on the organ.

--- Maximus/2 3.01