Re: Folk Theorem: Assemblers are superior to Compilers

Mike Elliott <elliottm@csulb.edu> wrote:
> Folk Theorems:
>[assember code is 1) faster and 2) smaller than compiler code]


jm@tao.univ-paris8.fr (Jean Mehat) writes:
>I think these folk theorems may as well be true. I thought at first that
>it may be false when the processor is designed for the compiler (like the
>RISC delayed branch), but I think it's just that no one, except a
>compiler's writer, cares to use delayed branch ; with reasonable training,
>anyone should be able to use it like a compiler.


The version I'd heard was that hand written assembler is better than
compilers on *CISC* machines (you know, the ones that cause loss of hair
in compiler writers :-) RISC machine compilers typically do better then a
decent human coder.


I do recall coming across an article that claimed this but can't remember
the reference :-(


>At least for C, what makes the compiler (relatively) inefficient is that
>the functions are compiled independently. It forbids register allocation
>across function calls. It constrains the compiler to make pessimistic
>assumptions on the register usage by the called functions. Didn't Ritchie
>accounted for a 10% loss when the Unix kernel was rewritten in C?


Unix rewritten in C --- this was on a CISC processor.


The generally agreed conclusion is that for CISC processors a *good* human
can do better (by a time factor of 2?) then a good compiler albeit at a
significant time cost.


On RISC processors people don't bother trying to use assembler. Partly
'cause they tend to be fast anyway. Also, 'cause producing optimised code
for a modern RISC processor requires knowing things like the depth of the
pipeline, whether it's superscalar and if it is, what exactly can it do in
parallel (Eg. seventeen integer opps and forty two floating point
operations).


This information is unfortunately not portable and will sometimes vary
between different implementations of the same architecture.


>The real point is that it takes much longer to write an assembler program,
>it's easier to make bugs, it's more difficult to understand and to
>maintain. These are the good reasons to use a decent high level language.


Of course the bottom line is that for non trivial tasks the choice of
algorithm can make a MUCH larger difference to size and speed then the
choice of language ... only a clueless teenager would try writting his/her
bubble sort in assembler to speed it up :-)


Michael
winikoff@cs.mu.OZ.AU
--

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