Until early 2009 [1], FSF forbade anyone from creating a plug-in architecture for GCC. I mean, you could do it, but it would not be integrated upstream, since FSF policy is to have copyright assigned to them before they integrate your changes into the project. If you were to create a plug-in architecture for GCC and sign the copyright over to them, then they could just sit on the code until GCC evolved to the point where your plug-in architecture's interfaces no longer matched GCC's. See the GCC Plug-ins Wiki page for the following ace quote: *"So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL?"*[2] In a nutshell, FSF dislikes DRM, so their solution is to create their own DRM system.
Increasingly, this political position is more and more irrelevant. Computer tools are so clever now that GPL v2 is simply not strong enough to mean anything in the sense FSF originally intended. It is so extremely sad that *compiler developers* do not understand that they can't truly complicate proprietary plug-ins simply by "unstable plug-in API". Once a shop has developed enough plug-ins and value, there will be an inflection point reached where it will make more sense to create a "module matching tool" [3] that defines interface relations [4]. Compiler developers should understand this: a plug-in API primarily separates functionality (what the plug-in does) from integration (how the plug-in is connected to the core). At best an unstable plug-in API can be a performance overhead inconvenience, but with tools like distcc you can just map out your code to many cores. It goes without saying that Richard Stallman is incredibly closed-minded and visionary. [5] has the a picturesque definition [6]. See also my comments in [7] and Thomas Lord's follow-up on the same page in the thread. [1] http://www.sdtimes.com/link/33218 [2] http://gcc.gnu.org/wiki/GCC_Plugins [3] http://www.cl.cam.ac.uk/~srk31/research/papers/kell09mythical.pdf** [4] http://www.cl.cam.ac.uk/~srk31/research/papers/kell10component.pdf [5] http://www.wired.com/magazine/2010/04/ff_hackers/all/1 [6] Time has not softened him. In our original interview, Stallman said, “I’m the last survivor of a dead culture. And I don’t really belong in the world anymore. And in some ways I feel I ought to be dead.” Now, meeting over Chinese food, he reaffirms this. “I have certainly wished I had killed myself when I was born,” he says. “In terms of effect on the world, it’s very good that I’ve lived. And so I guess, if I could go back in time and prevent my birth, I wouldn’t do it. But I sure wish I hadn’t had so much pain.” [7] http://lambda-the-ultimate.org/node/3696#comment-52599 On Thu, Jun 24, 2010 at 1:23 AM, Casey Ransberger <casey.obrie...@gmail.com>wrote: > Whoa, okay. Have to ask. GCC has an intermediate representation that's > intentionally hard to work with, and you're saying that Stallman did this as > a "political blockade?" > > I was under the impression that Clang got started up because some folks > found GCC to be too crufty, not too political. This doesn't seem to make > sense to me. Maybe I'm missing some context? Can you cite your sources or > elaborate on your point? > > On Jun 23, 2010, at 2:25 PM, John Zabroski <johnzabro...@gmail.com> wrote: > > This is not entirely true. Basile Starynkévitch has written GNU MELT [1] > as a way to circumvent "hard to work with" internal representation of GCC by > letting you create GCC plug-ins in a Lisp dialect. This basically > side-steps the traditional political blockade set-up by RMS. It is very > clever, and starting to mature; Basile has fixed a number of issues in how > he generates C code. > > I'm not sure about Gerry Jensen's idea, e.g. how much effort, whether it is > worth the effort, etc. > > Creating a VM for legacy code is also difficult, since it will run rather > slow unless you are a really good implementor (for example, the Hercules VM > [2] for simulating IBM mainframes is rather slow last I checked due to how > it has to intercept and translate instructions into the native > architecture). > > [1] <http://gcc.gnu.org/wiki/MiddleEndLispTranslator> > http://gcc.gnu.org/wiki/MiddleEndLispTranslator > [2] <http://www.hercules-390.org/>http://www.hercules-390.org/ > > On Tue, Jun 22, 2010 at 11:37 AM, Monty Zukowski <<mo...@codetransform.com> > mo...@codetransform.com> wrote: > >> GNU C was explicitly designed to make its intermediate representation >> hard to work with. LLVM is a more practical choice. >> >> Monty >> >> On Mon, Jun 21, 2010 at 6:02 PM, Gerry J < <geral...@tpg.com.au> >> geral...@tpg.com.au> wrote: >> > You may find the concept of semantic slicing relevant: >> > <http://www.cse.dmu.ac.uk/%7Emward/martin/papers/csmr2005-t.pdf> >> http://www.cse.dmu.ac.uk/~mward/martin/papers/csmr2005-t.pdf<http://www.cse.dmu.ac.uk/%7Emward/martin/papers/csmr2005-t.pdf> >> > There is software at: >> > <http://www.cse.dmu.ac.uk/%7Emward/fermat.html> >> http://www.cse.dmu.ac.uk/~mward/fermat.html<http://www.cse.dmu.ac.uk/%7Emward/fermat.html> >> > >> > One possible path to explore is to take GNU C etc intermediate >> > representation of source as the "assembly language" of a VM and reverse >> from >> > that to a more portable VM, as in Squeak or Java. >> > Perhaps Ometa could be combined in some way with FermaT to recognise >> > patterns and port legacy code to a fonc VM ? >> > >> > Regards, >> > Gerry Jensen >> > 02 9713 6004 >> > >> > >> > >> > >> >> >> >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > fonc mailing list >> > <fonc@vpri.org>fonc@vpri.org >> > <http://vpri.org/mailman/listinfo/fonc> >> http://vpri.org/mailman/listinfo/fonc >> > >> >> _______________________________________________ >> fonc mailing list >> <fonc@vpri.org>fonc@vpri.org >> <http://vpri.org/mailman/listinfo/fonc> >> http://vpri.org/mailman/listinfo/fonc >> > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
