🚀 go-pugleaf

> > Decent high-level languages ...
> > ... can also optimize the code better -- most hand-written
> > assembler is not highly optimized, because it's too much work for a human.
> 
> Most UNIX system hand-written assembly language is suboptimal because
> the programmers haven't learned the coding idioms and/or don't give a
> damn.  Humans can do a fine job of optimizing assembly language; they
> are much better at recognizing special case optimizations that are too
> expensive/unlikely to put in an optimizer.  My code, when it worked,
> was tight and more optimized than I have seen in most compilers...

Note that I said "highly" optimized.  When I say that, I mean the sort of
code where one spends long periods of time re-writing the code to make
the code a few words shorter or a few microseconds faster.  Note also that
I was not talking about "most" compilers -- I was talking about what the
language could do, i.e. what a really hot optimizing compiler could do.
The very best optimizing compilers are just as good at recognizing special
cases and exploiting them as humans, and they are much better at doing the
bookkeeping necessary to do this without error.  Building such a compiler
is a tremendous amount of work, of course, not least because one must teach
it about all those obscure special cases.  (The Bliss-11 compiler actually
looked to see if it could save a word of "immediate" data by using the
next instruction's opcode as the data.  Few humans go that far!)  It also
tends to be huge and slow.  But once you've got it, it's a much better way
of producing really hot code than doing it yourself.

I fully agree that human assembler programmers can easily produce rather
better code than the mediocre results from many compilers.
-- 
Usenet(n): AT&T scheme to earn
revenue from otherwise-unused	Henry Spencer @ U of Toronto Zoology
late-night phone capacity.	{allegra,ihnp4,decvax,pyramid}!utzoo!henry