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