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

john.r.strohm@BIX.com wrote:
> 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.


Historical note: There were two FORTRAN compilers for the CDC 6000
series. The RUN compiler was intended for development and student use.
It emphasized very rapid compilation - and it was, indeed, *extremely*
fast. However, its speed came at the expense of very simple code
generation. It did essentially *no* optimization; code was generated
from a series of simple templates. In fact, the code generator was so
simple that one could "de-compile" the code: With experience, it was
possible to re-construct the FORTRAN code from the executable. At one
time, I worked at a help desk for CDC FORTRAN programmers. Sometimes
they'd come over with a link map, an octal dump - and no listing. I'd
blow them away by looking at the octal dump, writing down some code, and
saying: You have a bug in code that looks more or less like this. I
would usually come very close. BTW, for small programs, the 6600 was
fast enough that even code generated this way gave acceptable
performance.


(The reason the compiler was called RUN was that the resulting control
card was just: RUN,FOO where FOO was your FORTRAN source.)


The other compiler, FTN, was an entirely different story. It did all
sorts of optimizations, and generated some amazing code. It payed,
needless to say, in compiler performance. At high levels of optimiza-
tion, it could chomp for a while. (A goal for FTN was that it replace
RUN; so its optimizations could all be turned off. The theory was that
at the lowest level of optimization, it would be as fast as RUN. As far
as I know, that never happened - there was just too much extra super-
structure in FTN (needed for the optimization components) for it to
match the very simple-minded speed demon that was RUN.)


To return to the underlying question - could a skilled programmer beat
the compiler: The answer for FTN was yes, absolutely. The scheduling
constraints for the multiple 6600 functional units were tricky, but once
one got used to them, they weren't hard to deal with. (In fact, the
6600 assemblers were designed to make things clearer to you. For
example, the names of the instructions immediately told you what
functional units they used; and part of an assembler listing showed you
how your instructions aligned with word boundaries.) As always, for a
*large* program, the compiler would win simply because a human being
would eventually get bored and make mistakes. And an optimal piece of
code written by a human would rapidly become non-optimal as changes were
made. Still, for stable inner kernels that would be used enough to make
every microsecond count, there was a role for assembler hacking - as
there still is today.
-- Jerry


--

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