Path: utzoo!telly!ddsw1!lll-winken!uunet!tut.cis.ohio-state.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson
From: wilson@uicbert.eecs.uic.edu
Newsgroups: gnu.gcc
Subject: Re: RTL Code and Debugging Tools
Message-ID: <102900002@uicbert.eecs.uic.edu>
Date: 13 Jan 89 00:05:00 GMT
Lines: 58
Nf-ID: #R:<8901110040.AA09549@hermite.mit.:-36:uicbert.eecs.uic.edu:102900002:000:3023
Nf-From: uicbert.eecs.uic.edu!wilson    Jan 12 18:05:00 1989


   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)