FTN Compiler (was: C code .vs. Assembly code)

> Scott A. Berg 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.


I don't believe this. My memory of RUN was that it was an older and
less optimizing compiler than FTN (perhaps I am wrong on that) I
frequently hand-tuned inner loops on assembly language on a CDC 6600
and could consistently speed things up over the code produced by the
FTN compiler. I doubt that I could write a large program and make it
run faster than FTN - the optimum approach was to just hand-code the
tight loops. One simply could not afford to spend the time hand-tuning
an entire program.


One optimization that the compiler did not have which was a standard
assembly language programmer trick was loop rotation. As jumps were
slow, you wanted to make sure you had as many slow functional units
(esp divide) busy while you jumped back to the top of the loop. This
made sure that the functional units twiddled thumbs for as little time
as possible. Note that the compiler did do instruction scheduling, but
even so, I spent many happy hours adding up minor cycles and
scheduling by hand.


The FTN compiler was all written in assembly language(!!!) so the
programmers were all expert assembly language programmers. I still
think anyone who is not an assembly language expert should not be
writing an optimizer or code generator. Ultimately, one has to sit
down and read lots of assembly code and, when you find sequences that
make you want to throw up, work out how to fix them.


(PS. The FTN compiler had another interesting "hack". It generated
assembly code and contained its own assembler. You could use the OS
assembler to assemble this code rather than the inbuilt assembler, but
if you did, the assembly phase took about twice as long as the entire
compile would have using the inbuilt assembler.


To get speed, they built a tree indexed by the next letter of an
opcode. So, each node had a 26 word table attached. This allowed very
fast opcode lookup - a three character opcode required three loads -
but took a lot of space as the tree was sparse. They used the wasted
space for the rest of the code of the assembly pass - that is, the
code was embedded in the tables.


The neat hack is this - there were a set of macros to generate the
tables. These macros generated a free list of unused space. Then there
were macros that were used around each basic block of code. These
allocated memory from the heap previously created for the block of
code and ORG'd it. Hence, the packing of the code into the table was
completely automatic - this was heap management at assembly time using
assembler psuedo-instructions!


When I saw this as a young programmer I was awed. Now that I am an old
grizzled programmer, I am still majorly impressed. I wonder if anyone
remembers who wrote those macros?)






--

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