[comp.lang.c] code optimizers

madd@bucsb.bu.edu.UUCP (02/17/87)

In article <531@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) writes:
>I once heard a story from a compiler deity in which some dude wrote a
>FORTRAN source code optimizer.  It read FORTRAN source and produced
>FORTRAN source which was "better".  It supposedly did better than the
>IBM G (or H, whatever the heavily optimizing IBM FORTRAN compiler was
>called) optimizer.  This could be fiction.

We have a prof. who once wrote a disassembler in lisp that produced
better source code than the original programmer.  The program was
used locally to get source to programs so that they could be patched
to run on our local OS.  He took it off the system when people started
using it to steal programs.

(This is just random information)

jim frost
madd@bucsf.bu.edu
..!harvard!bu-cs!bucsf!madd

jcollas@ll-xn.UUCP (02/20/87)

In article <745@bucsb.bu.edu.UUCP>, madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) writes:
> In article <531@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (dlsh)) writes:
> >I once heard a story from a compiler deity in which some dude wrote a
> >FORTRAN source code optimizer.  It read FORTRAN source and produced
> >FORTRAN source which was "better".  It supposedly did better than the
> >IBM G (or H, whatever the heavily optimizing IBM FORTRAN compiler was
> >called) optimizer.  This could be fiction.
> 
> We have a prof. who once wrote a disassembler in lisp that produced
> better source code than the original programmer.  The program was
> used locally to get source to programs so that they could be patched
> to run on our local OS.  He took it off the system when people started
> using it to steal programs.
> 
> (This is just random information)
> 
> jim frost
> madd@bucsf.bu.edu
> ..!harvard!bu-cs!bucsf!madd

Sorry to beat up a good piece of 'random information'.  The disassembler
in question (it really WAS written in LISP) could read IBM 370 object
decks and turn them back into IBM 370 assembler source.  It had the
amazing capability to turn inline instructions generated by macros back
into the macro forms.

It could not write better code than it was given.  (call me a spoilsport ..)
It could, however, totally eat up all the machine resources at one's
disposal.  And even more.

At costs like these, no one used it for getting munched programs back.
Much easier to use JHP's disassembler written in pseudo-Fortran.

So much for legends.  The hottest optimizer I've heard of is SUN's 'iropt'.
Supposedly does a nice job on any language, but I've only heard of its
use on FORTRAN and C.

	-Juan Collas, MIT Lincoln Laboratory

PS.  I wrote a disassembler with friends that did what the LISP one did.
     Ours was written in 370 assembler but didn't handle all the macros
     that Uncle Willy's did.  Of course, ours was MUCH faster.
     

mccaugh@uiucdcsm.UUCP (02/21/87)

 Just for the record:
 1) Having extensively used FTN-IV-G along with assembler programs, I can
    safely say that the "G" version was not the "optimized" FORTRAN;

 2) On the other hand, the "H" version was definitely optimized: unlike
    many compilers of its vintage (which were very memory-conscious), the
    "H"-optimizer bothered to keep the entire parse-tree intact for optimi-
    zation, which accounts for its particular success as a FTN-optimizer
    (the more info at your disposal -- even at the expense of memory -- the
    better position you are in to generate "optimal" code). For more details,
    consult "Compiler Construction for Digital Computers" by David Gries (2nd
    edition -- most readable if you speak IBM-360).