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