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?