Re: lcc intel backend? compile time?

(Gavin Thomas Nicol) writes:
> [fast compilation...] makes [lcc] ideal for the development stages where
>fast compile times are more important than good code [...]


This has been the conventional wisdom for at least as long as I can
remember (so I'm young). But frankly, I've never had undue difficulty with
the compile time of small-to-medium programs - particularly since it's
natural to break C source into compilation units that are updated mostly
in sips - on the processors popular since the microvax II, for example.
Building gcc or S, both of which I would consider rather largish, on a
microvax was something that one would start in the background, do other
things, and then see how far it 'made.' Figure out what stopped it, then
start again. And for smaller programs, 1 to 5 seconds per source file is
quite reasonable to me, and that's what I've come to expect from sytems
ranging from turbo C or pascal on an 8088 to xlc/gcc on an rs/6000 (no
bashing please).


So I'm a bit puzzled by this compile time vs. code quality tradeoff.
Don't other people construct their programs incrementally? Doesn't 'make'
(or equivalent) make your life simpler? Can't you read news for a minute
if you changed an important .h file? Isn't it simple enough to make
CFLAGS = -O when you think it's just about there, then get a
congratulatory mineral water or coffee or jolt or beer while your host
environment produces somewhat faster code which may or may not fail
depending on its version number?


Or are all programs 'large' 'systems' requiring 'CASE' 'methodology?'


Naively,
rob
--
rob rob@dinner.asrc.albany.edu or rds95@leah.albany.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.