This week I proposed
killing gcjx and replacing it with the Eclipse compiler.
Per had looked into this before, but this proposal was triggered by a
comment that Andrew made on irc that same morning. I surprised
myself by taking to it with enthusiasm.

Since then I’ve done some more investigation. This project seems
very practical, and I think will let us have a 1.5 gcj much quicker.
There are a couple potential optimization regressions by going this
route, but these are fixable in the compiler without too much work.

I also spent a little time hacking on the eclipse compiler’s
driver, trying to get it in shape for an experiment to test this
plan. That turned out to be easy.

While doing this though I finally felt the sadness I knew would
eventually arrive. The trigger was something very minor — I was
looking at the eclipse compiler driver, and realized that on a lexical
level it is pretty ugly code. There aren’t many comments, and the
ones that are there aren’t very good; the class I was hacking on
didn’t have a very layout or even consistent indentation style. And
so I took a quick look at the corresponding code in gcjx… we’re
definitely losing something in this exchange. (But to be fair, the
driver is not exactly a core part of the compiler. I doubt it gets
much love.)

We’re not losing much though, and I still think this is the best
way forward. Plus, and this also surprised me, I seem to have gotten
whatever emotional fix I was looking for from writing gcjx. I started
it at a kind of professional local minima, and writing it helped
remind me that I’m reasonably competent at this programming thing.
Now I’m on to feeling inadequate at a higher level.

Future compilers

I think some aspects of gcjx should be emulated in all future GCC
front ends. For one thing, front ends should have their own
representation, derived from the language being compiled — they
should treat GCC trees as a target format, not a high-level
representation. Trees aren’t statically typed, and they carry too
much other baggage as well.

Second, front ends ought to be written as libraries. These days
it isn’t enough to write a traditional batch compiler — you really
want to look ahead a bit and consider IDE indexing, incremental
compilation, and other uses of the parser and semantic analyzer.

More recently I’ve been interested in applying this treatment to
the C++ compiler. Recently I’ve been surprising myself quite a bit; I
was never interested in C++ compilation at all until the last few
months.