Hugh Leather wrote:
Aye up Basile,
Thanks for wading through my gibberish :-)
*Differences with other proposals.*
I'll have a stab at some differences between this system and the
others. But, this is going to be a bit difficult since I haven't seen
them all :-)
*Separating Plugin system from appliction*
Libplugin ships as a library. Apart from a few lines of code in
toplev.c, the only other changes to GCC will be refactorings and
maybe calling a few functions through pointers.
The point is who will do the refactoring you mention? We should not
expect tons of other people to rewrite their pass for us... This won't
happen (and conversely I am not able to rewrite other people's passes;
GCC is really complex for me).
I actually don't understand well what kind of plugin proposal will make
into the trunk. Let's assume that the trunk will go in stage 1 on
Christmas 2008, and that all the legal issues are solved (ie a runtime
license is *defined* and accepted and explains what kind of plugins are
GCC compatible) at the same time.
It is late for me, and I am dreaming of Santa Claus :-)
So let's suppose that Santa Claus came and give us (on end of december
2008) the runtime license and the stage 1.
What happens next? What kind of patches is sent to gcc-patches@ and who
will have time to review them?
I think it's important to separate the plugin system from the
application. Doing plugins well, IMO, requires a lot of code. It
shouldn't be spread through the app. It also cleanly separates
plugin mechanism from the actual extensions the app wants.
Finally, plugins have to be extensible too. They should really be on
a nearly equal footing with the app. Otherwise plugin developers
who want the plugins to be extensible will need to reimplement there
own extensibility system.
The issue I see here is to get a consensus on these ideas and on your
code. (I have same frightenning feeling about trying to get some day
MELT into the trunk).
*Pull vs push*
Libplugin has a 'push' architecture, not a 'pull' one. What I mean
is that the system pushes plugin awareness onto the application
rather than requiring the application to call out to the plugin
system all the time.
I'm not sure to understand (I need to go to sleep) and I am concerned
about having any plugin (be it your's or Sean's or Tarek's etc...)
related code accepted into the trunk some day. I would dream of plugins
to be inside GCC before 2010, but I am not sure of that!
Here's an example of that. In GCC, passes have execute and gate
functions which are already function pointers. With libplugin you
can make these replaceable/extensible/event-like without changing a
single line of code in GCC.
I'll read again in detail your proposal later. But my main concern is
not technical (how to do plugins - we each have our ideas, and we
hopefully would be able to merge them), but more social: what are the
(future) constaints (notably legal & licence contraints)? what are the
technical counterparts? how to make some plugin code accepted in the
trunk (I don't care whose code it is; and I don't have any generic
plugin machinery myself: I feel that MELT could fit in most reasonably
defined & well documented plugin subsystems)?
Maybe some much simpler plugin mechanism code (perhaps from Mozilla
Treehydra) might be easier to accept into the trunk, not because it is
better, but just because it is simpler, and quicker to be accepted into
the trunk?
Actually, I still don't understand how exactly (socially speaking) are
big patches accepted into the trunk (at stage one) and how to help a
branch (or some other code somewhere else) to be more easily accepted
into GCC? Should big patches absolutely be cut into small understandable
parts? If in practice a succession of small patches has a much bigger
chance to be accepted into the trunk than a bigger one, I don't know
what will happen next.
In addition, I would suppose that the runtime license could *requires*
some technical behavior by the plugin machinery, and such requirements
may perhaps prohibit more technically advanced solutions.
I'm really impatient to understand what kind of plugins will be
permitted (and when) in GCC, and also what kind of plugins will be
disallowed [this could mean more than the definition of a proprietary
plugin]. So far, I have no idea (because I am not a lawyer and because I
don't know anything about the current work on the runtime license).
Perhaps a microscopic plugin feature is better than a better designed
one. A miniplugin mechanism is enough to add more advanced mechanisms
(like your libplugin proposal, & perhaps like my MELT branch) inside,
themselves implemented in dlopen-ed *.so.
Maybe we should wait till at least end of october for some input (even
unofficial rumors) by the few people working on the runtime license.
I think that most of the issues are not technical here, but legal (the
future runtime license) and social (get some plugin code accepted in the
trunk).
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} ***
