On Mon, Jun 06, 2011 at 12:55:20PM +0000, Joseph S. Myers wrote: > On Wed, 1 Jun 2011, Basile Starynkevitch wrote: > > > In my view, you are talking of the mythical > > ModularGCC project, >
Then, very probably, I Basile don't understand what is called "modularization", and "defining a stable API" inside GCC. Don't forget that I am not a native English speaker, and there are often (human) languages issues. (this explain why my emails are somewhat repetititive: I don't feel confortable enough in English, so I need to explain more; I'm sure that if many people on this list had to write only in French, they could be more in trouble that what I am in English). > While there is a serious problem with a lack of reviewers reviewing > modularization patches (such as Joern's patch to avoid target.h including > tm.h, now in its fourth ping > <http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00307.html>), it's anything > but mythical. > > > which should be a mega-patch, 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 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. An old example was the X10 to X11 transition for graphical libraries (that easily shows my age; it happened probably in the late 1980s). With X10, only one graphical connection was possible (and it was a global variable). With X11, you can have several Display*-s (even if most applications had only one single instance of it). And that modularization required redesigning the full X programming API. In my naive opinion, it would not have been possible in many incremental patches. 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). > Nonsense. It should be hundreds, maybe thousands of separate incremental > patches. While, for example, there shouldn't be an exactly one-to-one > conversion of the 716 remaining target macros into hooks, 716 patches > would be a much more appropriate conversion than one mega-patch. > > > and I never saw it on > > gcc-patches@ so far. > > Then you can't have been paying attention to gcc-patches over the past > decade. There have been thousands of patches cleaning up some aspect of > compiler internals rather than directly changing the compiler's behavior, > and many of those have been improving modularity. If you want > modularization, insulting all the people who have been working on it by > calling their work mythical is not the way to go about it, and nor is > complaining about the lack of modularization. My point is that defining what is a modular GCC is definitely out of reach for me, because it would (in my view, which is perhaps wrong) require an understanding of the totality of GCC. Very few people have this understanding (I certainly have not it; there are many parts of GCC I know nothing about). So my belief is that only very few people (probably, mostly the global reviewers, i.e. those few heroes having a profound understanding of all GCC) could even define that modularity. Other people could perhaps implement part of it, but few can have the big picture in their head (I certainly don't and probably never will.). > 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 not convinced plugins are the > best tool for this, but I'm sure appropriate tools would help. So if you > wish to be an effective advocate for plugins, stop talking about them in > isolation and produce real self-contained modularization patches to GCC > that can be reviewed on their own merits - then explain how the use of > plugins was what allowed you to produce a hundred 1000-line patches in a > day, and to revise the whole hundred-patch series quickly in response to > review comments. Once you have concrete plugins of real use in improving > GCC, the patches to GCC to allow those plugins to be used will be of a lot > more interest.) I feel that modularization will help plugins, but I don't know if the opposite is true. I definitely did not want to be agressive towards any one when speaking about modularity. I just believe there is a terminology gap. For me, a fully modular (& hypothetical) GCC would be a software into which we could, for instance, run a gcc-5.2 compilation in one thread, and a gcc-5.3 compilation in another thread, and they will be able to work in parallel -ignoring each others, because not naving any common data-. (I don't claim that running two compilers in two different threads of the same process is a sensible thing; I just want to explain what I thought "modular" means.). And a "stable API" is above all a documented API. My sad feeling is that the (licensing) difficulties in generating (imperfect) documentation from header files are in practice a major issue here, because (as e.g. GTK demonstrates) generating some documentation from some header files is in my view a practical way to get some documentation about an API. I am quite pessimistic about the noble idea of having a full documentation of the GCC API appear (most of GCC functions are not documented at all in the GCC internals documentation on http://gcc.gnu.org/onlinedocs/gccint/ ). I also admit that the major more modular API (in particular the lang_hooks) are still today the parts of GCC I don't understand much. In my bad english speaking perception, cleaning GCC is not exactly the same as modularizing it. I apologize if saying that GCC is not modular enoguh was percieved as insulting. It certainly was not intended to be so. I am not able today to define precisely what are GCC modules, or even to give an approximate number of them. (and from what I understand about LLVM -which is not very much- I would imagine it could be called more "modular" than what gcc 4.6 is). The only numbers regarding GCC organization I know are today: the three layers (front-end, middle-end, back-end), the 250+ passes, the 1800+ GTY-ed types. I feel they could not be called modules (but I might be wrong). Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
