Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

Scott A. Berg wrote:
>I just heard a lecture by Peter Dibble, PhD of Iowa State University
>and Microware where he stated that a good assembly language programmer
>can consistently write code that takes up to 30% less execution time
>than code generated by a compiler. He has a long list of examples.
>He is also quick to add that this sort of code takes a VERY long time
>to write, requires a huge amount of obscure knowledge and experience,
>is often difficult to understand, and should be used sparingly.


Counterexample.


In the late 1950s, compilers were produced that routinely produced
code that took less execution time that code generated by expert human
assembly language programmers. This should have settled the argument,
but it did not. I believe these were FORTRAN compilers.


Counterexample.


The RUN FORTRAN compiler for the 1960s-vintage Control Data 6600
scalar supercomputer did an incredibly good job of generating optimal
code sequences that took into account ALL of the quirks and timing
considerations of the processor. It was MUCH better than human expert
assembly language programmers, for the kinds of things that FORTRAN
compilers for a scalar supercomputer typically needed to do.


Counterexample.


The Jovial J3B compiler for the M362F firecontrol computer for the
F-16A/B routinely generated better code than human assembly language
programmers. This compiler was in production use in the mid-1980s; I
expect it is still in use, because F-16A/B is still flying. M362F had
some interesting quirks; the compiler was quite capable of remembering
intermediate results across several pages of generated assembly code.


Partial counterexample.


F-16C/D used Zilog Z8002 and MIL-STD-1750A processors. General
Dynamics/Fort Worth Division procured Jovial J73 compilers from two
vendors, targeting both processors. Those compilers were required to
come within 15% of the code generated by an expert human assembly
language programmer. I was one of the human experts in one round of
benchmarking. Part of what we did was look carefully at the generated
code and tell the compiler vendors what their code generator was doing
that caused it to miss the 15% mark. IN ALL CASES, the compilers
missed the mark that time around. IN ALL CASES, it was due either to
(a) the compiler didn't use a specialized MIL-STD-1750A instruction
that saved a few instructions, or (b) the compiler had some "quirk" in
the way it generated code that caused it to generate a few extra
instructions. IN ALL CASES, we were able to tell the vendor exactly
what they needed to fix.
--

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