Re: Self + GCC

[urs@cs.stanford.edu (Urs Hoelzle)]

Re the "Self on [your-favorite-OS/your-favorite-architecture]" thread:
we'd love to make Self available on more platforms.  An OS port
shouldn't be too hard, as long as the OS is Unix-like; the biggest
problem would probably be the signal handling code (non-blocking I/O
etc).

Porting to a different architecture is harder since it requires
rewriting the compiler back end and run-time glue.  Given an acute
lack of time (some of us are trying to graduate :-) it's not likely
that we'll do that anytime soon.  But if someone wants to give it a
shot I'm sure we could at least give some support in deciphering the
code... 

> What's the possibility of using GCC as a compiler backend for Self?
> I was extoling the virtues of Self to rms, who didn't realize it was
> free, and is now much more interested in it, but would like it to be
> portable. 

It would be terrific to be able to use the GCC back end - porting
would be so much easier.  Last time I looked into it, I found three
problems, all of which might require some serious hacking to fix:

1. GCC is not GC-aware (despite it's name :-).  To support garbage
   collection, the runtime system needs to know where the pointers are
   (both as constants in the code and in terms of register contents).
   This requires the back end to "document" its optimizations
   carefully, i.e., to output some descriptors telling the GC system
   where things are.

   Eliot Moss' group tried doing this for Modula-3, and as far as I
   know they ran into some problems.

2. Self needs full source-level debugging.  That is, every
   optimization has to be 100% user-transparent.  As far as I could
   tell, GCC would need to be changed quite a bit to support this.

3. Compilation speed.  Self uses run-time (dynamic) compilation -- the
   first time you pop up a menu, the menu-popping code has to be
   compiled.  Though the GCC backend isn't slow in conventional
   (batch-style) terms, it is probably too slow for interactive use.
   Especially if it goes through the extra step of generating assembly
   text.

Then there are some more minor issues, such as generating code into
memory rather than into a.out or .o files, but that probably won't be
a biggie. 

Maybe someone more familiar with the GCC back end could comment on the
feasibility of making these changes?

-Urs