Re: High Level Language vs Assembly

In article 01-02-138,
jacob navia <jacob@jacob.remcomp.fr> wrote:
>A compiler must be correct for all cases. This means that will never
>be as clever as the programmer doing a concrete program.


Often cleverness is less important than bookkeeping ability. A
compiler can remember, and track the implications of, unlimited
volumes of clerical detail. This means it will often be able to
optimize better than a programmer.


The programmer necessarily has to write a *family* of programs. His
inability to handle massive detail easily means that large-scale
rethinking for every change is impractical. The inevitable small
changes during debugging and testing must not bring the whole thing
down like a house of cards.


The compiler can, and does, start from scratch every time, optimizing
that *exact* program as thoroughly as it can, with no need to be
concerned about vulnerability to small changes.


>Take for instance a routine that uses often a global variable. A human
>assembly programmer, knowing the use of the variable in the program,
>can cache that in a register. The compiler can't since it could be in
>principle modified by another thread. It must generate code to read it
>each time from RAM.


Modern compilers can, and do, cache such things in registers... unless
they are declared "volatile", which is how you tell the compiler that
the variable is subject to behind-the-scenes changes.


>I like assembly. For instance, I discovered that generating in-line a
>loop to replace strlen is actually smaller in code size, than the call
>itself!


Poor compiler you've got there. Good ones will inline strlen if that is
a win. It has never been the least bit difficult for an assembler
programmer to beat a poor compiler.
--
When failure is not an option, success | Henry Spencer henry@spsystems.net
can get expensive. -- Peter Stibrany | (aka henry@zoo.toronto.edu)

Return to the comp.compilers page.
Search the comp.compilers archives again.