Diving Into GCC: OpenBSD and m88k
BSD Forums writes "This OnLamp article by Miod Vallat describes how the m88k-specific backend of the GNU C compiler, gcc, was fixed, from the discovery and analysis of the problems to the real fixing work. Since it started with almost zero gcc internals knowledge, it should be understandable by anyone able to read C code, and proves that diving into gcc is not as hard as one could imagine."
A while back, when I was hacking a new option into the Objective-C compiler (for 2.9.5), I ran into an interesting duality in GCC. Some things are really easy to change, others considerably less so.
The back-end of GCC is pretty cleanly designed, so it's not too hard to change the object code output for a particular processor, or even to add support for a new processor (as long as it's a 32-bit, RISC processor with lots of general purpose registers).
On the other hand, the front end is a mess. Heaven help you if you want to change the parser behavior. Even something as basic as the processing of command-line options is needlessly complicated. The GCC driver program and the C frontend use entirely different code for processing the command line.
Changing the output of the compiler was actually easier than getting the options passed from GCC into the Obj-C frontend so I could actually turn the new behavior on and off.
I even found out that there were several options in our version of GCC that didn't do ANYTHING, since they never actually got passed down to the compiler from the GCC driver.
Someday, I may get motivated to sit down and make a real effort to fix this mess. I wonder if anyone would care?
-Mark
And that's why the front end was reworked for the GCC 3.x.x compilers. Supposedly they are much cleaner, and tasks like tracking the newest features of standards are easier now.
If tits were wings it'd be flying around.