Datalight faster than 4.2, why?

[Chris Torek]

In article <2786 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) writes:
>... having a separate pre-processor will slow the compiler down
>considerably, but is it an advantage?????? It only gives you a
>certain amount of convenience in implementing the compiler.

Not so!  There is another advantage.  The preprocessor can be used
alone, or in combination with programs other than the C compiler.
This is the `software tools' philosophy: if you can make a clean
conceptual break in a task, make that break programmatically; you
then have a set of tools that may be useful in surprising ways.

>It makes a *lot* of sense to have the cpp/lexer/parser in a single
>pass - Much code can be shared.

It makes a lot of sense, in terms of time to code generation, to
put everything in a single process.  But I am not now willing to
rewrite the entire cpp/ccom/c2/as sequence as a single program.
It is simply not worth the effort to me.  It might be worth the
effort to others, though.  And again, we would still need a separate
cpp to make the kernel, and I would either have to include the work
`inline' (asm.sed for you 4.1 and 4.2 folks) does, or have a separate
ccom and c2+as phase.

>If compiler A has more passes than compiler B, it doesn't mean 'A'
>is better or more sophisticated - It could just mean that the
>implementors of B did a better job.

Or that the implementors of B were aiming for speed, while those of
A were aiming for reusability.  Or that A runs on smaller machines;
this is probably the real reason for those multi-pass PDP-11 compilers.
They just turned out to be a good idea (in some ways).

In article <250 at myrias.UUCP> cg at myrias.UUCP writes:
>What contortions the compiler goes through is irrelevant - how long it
>takes and how good the resulting code is are what's important.

Important to whom?  What about those writing the compilers themselves,
or using parts of them?  Did you know that the F77 and Pascal
compilers share the same code generation program, which is itself
a modification of the original second pass of the C compiler proper?
And all the compilers share the assembler, which does the grunge
work of optimising branch instructions on a machine where conditional
branches have a limited distance, but unconditionals do not.

>We all know that most UN*X C compilers are hogs! I will re-iterate
>the question that was asked:  Why aren't there any decent C compilers
>provided with UN*X systems?

>From whom did you buy your UN*X systems?  If Berkeley, what did you
expect from a research institution?  `If it were any good we would
sell it.'  (Who said that?)  If from a `real world' company, complain
away---but not to us!
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu