I'll try to keep my short comments short ;-)

A friend of mine has just sent a link to the GNU Smalltalk JIT project:

   ftp://alpha.gnu.org/gnu/lightning-0.9.tar.gz

It is interesting to note that GNU ST, like Self, has come back from the dead
around last November. I looked through that code and it seems to do with macros
what the Self compilers do with inlined C++ methods. But since it is more
declarational (if such a word exists) it will probable be easier to add new
CPUs.

The one thing I don't agree with them is that "scheduling doesn't matter". It
might be pointless to second guess the reorder hardware in the Pentium III, but
it does matter very much on simple VLIW processors (like Crusoe or the Philips
Trimedia) and EPIC/Merced/Itanium like chips. In fact, I think (as we saw on
the Intel 860) that this is where we can not only tie with the C compilers, but
actually beat them!

Of course I agree that wasting time to generate good code is a bad idea 95% of
the time. That is why we have Hotspot (adaptive compilation) - so the system
can identify for itself the 5% that need to be fast and automatically let loose
the good code generator on it. Something like Lightning is good enough for the
rest. In fact, I had initially considered having a simple interpreter (like Dan
suggested) interpret the compiler compiling the compiler :-) but now I think a
two compiler system with cross-compilation for porting might be best.

Conclusion: if we use an adaptive compilation scheme which is easy to port
using tables for each CPU and these tables include scheduling information that
is aggressively used by the "good" compiler, then I think we can write
performance critical code in pure Smalltalk (not slang) and still outperform
the current C based system on future processors.

-- Jecel