Re: [RFC] Let's kill specs, completely rewrite gcc.c

["Zack Weinberg" <zackw at stanford dot edu>]

I wrote up a similar proposal some time ago.  It had the same plan -
rewrite gcc.c - but a completely different goal.  I wanted to make the
specs language powerful enough to express everything that's now done
with hardwired paths and language specific driver hooks, and make it
easier to read/write at the same time.  The idea was you'd have just
one driver executable, and all the user visible front ends (gcc, g++,
cpp, ...) would be scripts that used it.  This would also make -V and
-b work reliably (between versions with the new driver).

I still think this is a worthy goal, but wouldn't be opposed to going
all out for table driven custom C, either, as long as it's easier to
work with.

You might be able to get a decent speedup out of the existing code by
sorting all the options into pigeonholes by their initial letter.
Then the spec scanners could just look in the appropriate pigeonhole.
Things like %{D*} would have zero additional work to do.  This might
be just as much work as a complete rewrite, though.

Whatever happens, I'd suggest implementing the guts as a dynamic
object that Make etc. could use directly.  I don't have a clear idea
how this should work, but if you get it right you could cut out all
the process creation overhead for invoking the driver on every
compile.

My old proposal is at http://gcc.gnu.org/ml/gcc/1999-03n/msg00754.html.

zw