ajensen (@.) on 6/24/10 wrote:
---------------------------
>Gabriele Svelto (gabriele.svelto@gmail.com) on 6/24/10 wrote:
>What's wrong with it?
>
>Well as far as I can gather, the problem is not the feature richness, but the monolithic
>architecture. A large project buildt more modular would be easier to maintain and
>move forward as some parts gets outdated and new ones are added. Am I wrong? Its
>not like I'm trying to force feed this into capabilities like mr. Schmidt here,
>but I'd really like to know why it is often seen as convoluted and unmaintainable.

I suspect that one of the issues making GCC larger/more-complicated/harder-to-maintain is that the architectures that it supports are much more varied (weirder) as a group than any one is individually. The compiler internals have to handle the collective strangeness.

A few examples:

*) Some of the older RISC architectures (I'm thinking SPARC) have these things called "branch delay slots." If GCC wants to support SPARC, then some parts of GCC need to be aware of this concept. My guess is that this concept impacts internal data structures over large parts of GCC and code that needs to deal with this concept is also all over GCC. The concept of "branch delay slot" isn't (and can't be) neatly encapsulated in a small, modular part of GCC.

*) Itanium EPIC is substantially odder than many of the RISC architectures we had in the 1990s and 2000s (explicit instruction bundles that *logically* execute together, predication [yes, ARM has this to a degree]). Again, as with "branch delay slots", these oddities probably spread throughout GCC.

*) Unless you want a totally different instruction scheduler for each target architecture (and maybe you do ... maybe this is what GCC already does?), then you need some sort of super-set of all the constraints one can have when building instruction sequences (the branch-delay-slot is one example of this sort of constraint). The super-set is going to be more complicated than any one constraint set.

The only obvious way to simplify things is to either:

a) Cut down on the architectures supported, not because of number but because of differences, or
b) Maybe (but I doubt it), totally re-architect the whole thing with the idea that we have a better idea of the range of capabilities/limitations and can do a better job designing the internals with this knowledge (my opinion is that this approach won't work).

-Mark Roulo