Sun, 29 Jan 2006
gcjx non-status
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 compilersI 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.
posted at: 13:27 | path: /software/gcjx | permanent link to this entry
