Datalight faster than 4.2, why?

Gregory Smith greg at utcsri.UUCP
Sat May 31 10:03:25 AEST 1986


In article <1723 at umcp-cs.UUCP> chris at maryland.UUCP (Chris Torek) writes:
>In article <2786 at utcsri.UUCP> greg at utcsri.UUCP (I) write:
>>... 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 may also be surprising in useless ways ;-)
The problem with cpp is that it is rather C-specific - it knows the
C comments, and string formats, and that 123.e+12 does *not* contain
an 'e' which is a candidate for #define expansion ( at least it should :-) ).
Constrast to m4 which is a much more general beasty.
In general, though, I agree with this idea.
>
>>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).
>
Yes, and yes.

>In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)

-- 
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg



More information about the Comp.lang.c mailing list