This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

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

My old proposal is at


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]