ghoti@BOURBAKI.MIT.EDU (01/11/89)
In his interesting article, Patrick Paroubek tells us that he has separated the code generation from the rest of GCC in connection with his work on the experimental language CLIP. He then presents excellent arguments why it may not be such a good idea to do so in general. Of course, the role it plays in his own research shows that it also sometimes IS a good idea to separate the code generation part, as I am sure he will be the first to agree. I would like to point out another reason why it might be a good idea. Namely, there is presently no systematic way to debug GCC and the prospect of being able to separate the various components of GCC and test them individually is rather appealing. In particular, it would be desirable to be able to separate the code generation from the rest of GCC and compile directly from RTL. Some people already know how to do this. Patrick is one of them. Also, I received a message from Michael Tiemann some time ago saying that he had also written such a thing and saying that he planned to release it in the near future. I for one would be very interested in trying it out when it does become available. Patrick also points out that the code generator doesn't accept all possible RTL expressions, but only the ones likely to be produced from the source language. This can be viewed as saying that the formal description of RTL in the GCC documentation does not accurately describe the language actually accepted by the code generator. Hence, it is natural to ask what must be added to the formal description of RTL to correct this situation. Allan Adler ghoti@hypatia.mit.edu
ghoti@BOURBAKI.MIT.EDU (01/11/89)
Regarding the following passage from my earlier message on the subject listed above: "Some people already know how to do this. Patrick is one of them. "Also, I received a message from Michael Tiemann some time ago saying "that he had also written such a thing and saying that he planned to "release it in the near future. I for one would be very interested in "trying it out," I have received the following reply from Michael Tiemann: "I helped Patrick write his version when I was in Paris "this summer. RMS asked me not to distribute it, for the "reasons stated in Patrick's letter. " Michael." I have earlier pointed out the utility of being able to test the components of GCC separately when debugging GCC. Apparently FSF feels that cooperating with efforts to develop such a capability would be, in effect, giving aid and comfort to the enemy. I question whether this attitude is consistent with FSF's stated belief that it is healthy to be able to study the source code for the entire GNU system. In any case, I still think that the development of debugging tools is of value. Since FSF doesn't feel it is in its interests to cooperate with this suggestion for developing them, I wonder whether it has any plans of its own to develop and distribute debugging tools for GCC. (And please do not remind me for the one thousandth time that FSF has done more than enough by doing precisely what it has already done, as though there was also not room for constructive suggestions.) Sincerely, Allan Adler ghoti@hypatia.mit.edu
wilson@uicbert.eecs.uic.edu (01/13/89)
Does anybody have any alternative recommendations as to how to get
a multi-target back end easily? I understand RMS's objections to
distributing gcc's, but it certainly seems a shame.
I would guess that I'm not the only person who could use one and
that Scheme isn't the only language it would be nice to use it for.
(Imagine a family of GNU languages -- GNU Smalltalk, GNU Icon, etc.,
and only having to retarget one code generator for new architectures.)
Would it be reasonable to simply intentionally obfuscate the lines of
modularity and/or copyleft the software so that it's illegal to extract
the back end? (Yuck, but...) Using the obfuscation technique, would
it still be possible to straightforwardly get the benefits of new versions
of gcc?
Would it be objectionable to come up with a standalone virtual machine that
uses snarfed gcc code generator code? I'm thinking of a middle-of-the-road
VM that uses bytecodes but dynamically compiles them to machine code.
(Like the Deutsch-Schiffman Smalltalk technique, only more so.) This VM's
instructions and data formats would be a compromise between what's best
for Lisp and what's best for Smalltalk (sans graphics), but with a couple of
important Icon- and APL-like features.
(The basic idea is to support dynamically-typed, garbage-collected
languages in a fairly general way. I've already got a nice generational
garbage collector written in C, so that part's easy.)
The dynamic compilation trick is crucial; the VM could be used
for new languages without tremendous overhead just from incessantly
decoding the same sequences of bytecodes. (It seems to me that this is
a major strength of clever dynamic compilation -- it should halfway compensate
for an inappropriate VM design by glomming together sequences of opcodes
that "should" be one powerful instruction for a particular language.)
Besides supporting the prototyping of new languages, this VM would
itself be an experiment in dynamic compilation and tentative optimization
(something that's only been done for APL, as far as I know). My interests
are more in high-level optimization of polymorphic languages than in low-
level optimizations, which is why snarfing a back end is *so* attractive.
So now the question is whether this, too, would overly encourage people
to market their own commercial "front ends" (virtual images) to run with
the back end (virtual machine). On the other hand, I wouldn't expect the
performance of such a generic system to ever be awesome; maybe there's
not much danger. (Especially since any commercial product would probably
have to hack graphics support directly into the VM and therefore couldn't
use a standalone freebie.)
Any thoughts about this?
-- Paul
Paul R. Wilson
Electronic Mind Control Laboratory* (312) 413-0042
U. of Illin. at C. EECS Dept. (M/C 154) wilson@uicbert.eecs.uic.edu
Box 4348 Chicago,IL 60680 (* a.k.a. Human-Computer Interaction Lab)wilson@uicbert.eecs.uic.edu (01/18/89)
Apologies to anyone who sent me mail about my posting -- our site lost all of our incoming mail for a few days. Please try again. (You might want to cc a copy to wilson@carcoar.stanford.edu to make sure I get it.) Thanks, Paul Paul R. Wilson wilson@uicbert.eecs.uic.edu (and wilson@carcoar.stanford.edu)