Re: [tlug] Assembly Language v C and Embedded Development: !gcc for PIC16F84

["Stephen J. Turnbull" <stephen@example.com>]

Lewske Wada writes:

 > How about
 > 
 > mov bx, ax
 > shl bx, 3
 > sub bx, ax
 > 
 > to get 7 times ax?

But that's a peephole optimization, and I really don't think you want
to compete with the compiler on remembering such optimizations.
Instead, you want to teach the compiler to do new ones as you invent
them.  The only real problem with this approach is ensuring they are
correct, but peephole optimizations are usually easy to prove correct.

Note that Small C had about a dozen such optimizations, most of which
simply corrected for really dumb code generation, but some of which
depended on seminumerical analysis like the above.  But Small C was
self-hosted; a cross-compiler on a modern workstation could surely
afford to do thousands of such, maybe millions with appropriate
structuring of the data on optimizations.

I think it would be also very hard to beat a modern compiler on
register usage, although I'm sure it's possible (the human assembler
programmer will choose algorithms he knows how to optimize, while the
C programmer isn't as likely to do so).

Of course, this is all theory.  If there's no open source compiler for
your platform, then (unless you're going to write a lot of code for
it) you probably can't build your own library of optimizations.  If
there's no compiler at all, writing one (or retargeting one) is rather
expensive.