Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <12565@dog.ee.lbl.gov>
Date: 27 Apr 91 13:32:50 GMT
References: <21961@lanl.gov> <11129@ncar.ucar.edu> <22246@lanl.gov> <1991Apr24.174057.22470@ee.eng.ohio-state.edu> <22687@lanl.gov>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 42
X-Local-Date: Sat, 27 Apr 91 06:32:50 PDT

(I have tried to stay out of this, as arguing with Jim Giles is bad for
my disposition---everything he writes seems to me a vicious attack, as
if his postings were little rabid dogs, poised to bite the unwary; but
that is only my opinion.  At any rate, regardless of the merits of some
of his points [there are some merits!] I wish to make two comments.)

In article <22687@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>Only _one_ C implementation has been brought to my attention which
>does [inter-module] analysis _at_all_.  This is the MIPS C compiler ...

The MIPS compiler is definitely not the only such, though it may be the
only commercial one.  For instance, the Plan 9 compilers do much of
their optimization in the linker; there may be a special flag to
disable this in case the linker's optimizer is broken, but the default
is inter-module optimization.  (Indeed, the Plan 9 group have decided
they may have gone too far in that direction, as it takes over 30
seconds to compile the Plan 9 kernel from scratch, and if more of the
optimization were done in the `compiler' part more of it could be done
in parallel.  Would that gcc could compile BSD in under a minute, or
even under 10 ... ah well.)

>Finally, as I have pointed out before, I consider the MIPS method
>perfectly acceptable for all but commercial function libraries (which
>are inherently separately compiled so the vendor doesn't have to 
>distribute source). ...

Jim seems to be under the impression that in order to get the MIPS
Ucode optimizer to function, you must give it source.  This is not the
case.  One of the compiler options causes it to emit `.u' files (so
named simply to avoid confusion, no doubt; the only difference between
a .u and a .o file is that the latter contains much more machine code
and much less intermediate information).  These .u files can be bound
up in a library.  They are not source code (there are no syntax errors
in .u files) and they certainly could be distributed commercially.
They do require more time to load than an equivalent library of MIPS .o
files, which some commercial vendors might view an impossible barrier,
but that would be silly (vendors could distribute both formats, one for
`test compilation' and one for `final compilation', if compilation time
is considered important).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov