Subject: Re: ARGSUSED and friends
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/30/2000 12:12:51
[ On Sunday, January 30, 2000 at 03:19:00 (-0500), der Mouse wrote: ]
> Subject: Re: ARGSUSED and friends
> There is a tension here between two values:
> (1) One job per program, one program per job
> (2) Don't do the same thing two different places
> As you say, (1) certainly argues for making the compiler fast and lean,
> with minimal checking. (Indeed, carried to an extreme, it would not
> even do syntax checking, with the results for syntax errors being
> "whatever the implementation happens to give", the philosophy being
> that you should check the code before you compile it.)
Indeed and I can forsee a simple enough addition to the make rules that
would implement a mode where new code changes were always linted before
being compiled but un-changed modules would just be compiled if their
object modules had been removed.
> But (2) is also forceful. Putting the checking and the compiler in the
> same program means that neither has to duplicate work the other already
> does, by which I mean everything from parsing to data flow analysis.
> It also guarantees that you never find version skew between the checker
> and the compiler.
I think the basic goals of #2 are accomplished by sharing the duplicate
code between the compiler and the lint tool. There are already some
parts of a C compiler that are almost always implemented as separate
programs, some of which are obviously sharable, and indeed the
user-interface needs the compiler and the lint tool would suggest having
separate front-end driver programs in any case.
> There's yet another argument in favor of doing checking and compiling
> in a single program: that way seems to have less trouble finding people
> to work on it. Compare the amount of development available for new gcc
> work versus the amount of effort available for souping up lint and/or
> building a "lean and mean" compiler.
The problem is that to do all of the important checks that only a
lint-like tool can do you need a different back-end stage and sometimes
storage of intermediate parse trees (lint libraries), whether you always
run the lint-backend in parallel, in sequence with the code generator,
or from completely separate front-end drivers.
I would be extremely happy to see the GCC folks build such a back-end
(or accept and integrate one if it was built for them).
I'm also intruigued by the various potential benefits that can come from
having a completely separate pre-processor and parser for the lint
tool. I'm not yet convinced that these benefits are outweighed by the
cost of developing and maintaining them, especially given that such a
lint tool can be just as widely used as a portable compiler with many
code generators. Inevitable finger-pointing about which nit-picker is
right can these days often be settled by pointing at the standards
(not that I'm advocating current C standards as models of perfection!).
Unfortunately I'd rather use a compiler or lint tool than write one
(even though I think I'm still capable of doing minor maintenance on
There are, BTW, other freely available compilers (well at least one! :-)
that don't have GCC's bloat and from what I've heard often compare
favourably in their ability to generate good code. They also don't have
GCC's vast array of back-ends and host portability (yet)....
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>