On Mon, 6 Jun 2011, Basile Starynkevitch wrote: > Then, I don't understand what modularization should be. My point is, imagine > we want to get rid of most global variable and state (and indeed, we
I don't think this is what most people mean by modularization, although maybe some people want to get it (in particular areas) from modularization. > probably have much less of them than years ago, so there are definitely some > progress on that). My intuition was that would require passing extra argument > to many functions. My intuition was driven by observing graphical libraries > such as GTK3 or QT4. They provide almost no global state, except (I am > simplifying grossly) a single type (GtkApplication in GTK3, QApplication in > Qt) which encapsulate all of it. > > Now, if we wanted to pack all the state of GCC inside some (very few, > perhaps only one) variable, we would have to change most of the functions > inside it. Perhaps the patch would be cosmetic, but it certainly would be > very big. No, look at the incremental conversion of GDB to pass gdbarch parameters around rather than using a global architecture (so that different frame could have different architectures, for use in debugging Cell programs where logically some call frames were on the PPU and some on the SPU). That was done in a great many patches. Or for that matter look at my option-handling changes, where additional parameters have been gradually added in various places, with assertions about the values of those parameters when control passes from code using those parameters to code not using global state. Note that these parameters are added as a means to an end (because of a desire to make simultaneous use of multiple sets of state that was formerly global), not an end in themselves. > My intuition that for such major refactoring, many small patches are not > possible. I am perhaps wrong (or I put a different meaning in the > "modularization" word than you). Modularization means improving the separation of GCC into components (modules) with better-defined and narrower interfaces and dependencies between them; it has nothing to do with whether those interfaces involve global state, and nothing to do with whether those interfaces are stable between different versions of GCC. For example, converting target macros to hooks (and generally reducing the number of places that end up including tm.h, directly or indirectly) improves modularity, by narrowing the interface provided by the target module to a set of function pointers rather than target-provided headers with arbitrary sets of declarations and macros that are visible throughout the compiler. You might do this with a specific goal (such as a multi-target compiler which can compile different functions for different targets) or simply to clean things up. For example, the toplevel libgcc transition improves modularity by separating host-side and target-side configuration and potentially allowing libgcc to be built on its own, without needing a configured gcc/ build directory. Again, you might have a specific goal (building libgcc separately from the compiler) or you might not. > > Instead, demonstrate the utility of plugins by writing plugins to do such > > things as understanding inter-header dependencies and working out what > > source files actually depend on what headers, or automatically assisted > > conversion of target macros to hooks. > > I don't know well enough the lang_hooks to understand the above sentence. I'm talking about target hooks, not lang_hooks, and about header dependencies as described at <http://gcc.gnu.org/wiki/ModularGCC>. Making source files only include the required headers, and making the required set correspond to the features that a part of the compiler logically *should* be using, improves modularity. The front-end interface is much more modular than the back-end interface (there are some residual warts such as the special "convert" function name). -- Joseph S. Myers jos...@codesourcery.com
