I am very interested in this thread, but can't write a proper reply 
today. But here are some brief notes:

1) It seems some people are drooling over the prospect of the sources 
for the Animorphics VM being released. Given that the Self sources were 
released in 1995 and a cleaned up version in 2000 and nobody did 
anything with it (with the exception of Gordon Cichon and Harald 
Gliebe) I doubt there will be much more than "kicking the tires" if it 
happens. It is better to focus on the type system (which is out, after 
all) instead.

2) Machine code has been generated from Squeak in three ways:

 - Slang (Smalltalk without objects) to C using a translator in 
Smalltalk. For the interpreter and plugins

 - Bytecodes to PPC and x86 using a translator in C (Jitter 3). For the 
whole system

 - Slang (I think) to ARM using a translator in Smalltalk (by Alan P.)

The original Jitter generated threaded code and doesn't come into this 
story.

What we want is a Bytecodes to PPC, X86, ARM and MIPS (would those who 
care about Sparc, Alpha and SH please raise their hands?) using a 
translator in Smalltalk.

This would even allow the interpreter and plugins to be rewritten in 
proper Smalltalk. I'll address some concerns with this tomorrow.

3) short Jitter tutorial: by keeping code in bytecode form and 
translating to native code as needed, you get the best combination of 
low memory requirements and high performance. By compiling instead of 
interpreting you can use these tricks:

- generate one native code for each class inheriting a single bytecode 
method. This lets you move lots of lookups from run time to compile 
time. All message sends to "self", for example, become static calls. In 
fact, you might as well inline some of them which opens up lots of 
other optimizations

- the hardest code to compile is normally rarely (or never) used. Just 
skip it and put in a call to the compiler to retranslate the method if 
it turns out we really needed it. You can't do that with a traditional 
compiler but since we have it during run time anyway...

- trying to extract type information from the bytecodes is a huge time 
sink. But after you run the code a while, this information can be 
easily extracted by looking at the caches (PICs - polymorphic inline 
caches). Most code only runs once anyway, so just do a crude job to get 
it working and then if it is used a lot (a system hot spot) tell the 
compiler to try harder, but now with more information obtained from 
actually running the code

-- Jecel