Re: High Level Language vs Assembly

"jacob navia" <jacob@jacob.remcomp.fr> writes:


>A compiler must be correct for all cases. This means that will never
>be as clever as the programmer doing a concrete program.


That one cuts both ways:


A library routine must be correct for all cases. This means
that a library routine written in hand-coded assembler
will never be as clever as a compiler generating specialized
code for a particular call (e.g. after inlining or specialization)
can be.


If you never make use of library routines with reusable code, then
your argument may hold up. But if you never make use of library
routines with reusable code, then the amount of programmer time
that must be invested is huge -- this is expensive, and furthermore by
the time your product gets to market, there is a big chance that
someone programming in an HLL will have already captured your market.


>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.


The C standard doesn't say anything about threads, but IMHO it is
reasonable for a compiler to perform that optimization, and only flush
the value back to memory at thread synchronization points and at
thread switches. Variables which are accessed from multiple threads
without synchronization should be declared `volatile'.
(I don't know if many compilers perform such optimizations, though.)


Another alternative is for the HLL programmer to use an HLL that supports
explicit global register variable declarations, for example GNU C.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

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