Re: High Level Language vs Assembly

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


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.


Of course the linker could be changed to determine that that variable
is never used, after all, and optimize it at link time, but this is
rarely done.


Another stuff is, to add another example, rounding. An assembly
programmer will round to nearest, the compiler must follow the C
specs, truncate it in C (i.e. set the FP unit in the right rounding
mode), then make the operation, and of course restore the old setting
of the FPU. This is surely less efficient. (For x86 architectures
obviously)


Big projects can't be done in assembly. But small parts can be recoded
in assembly. The gain can be considerable, or not, as stated in
another contributions, it can be even faster to change the algorithm
in a HLL.


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! It contains more instructions but they are shorter. Adding up
the size of the pushes, and the stack adjustement after the big call
instruction you come out with smaller programs by inlining!


This reduced program size quite considerably in the case of
strlen. But it would be difficult to do this in assembly without a
macro facility. And then, when you start considering macros in asm,
they are more and more near a C like syntax anyway.

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