Animorphic ST (Strongtalk) released!
Jecel Assumpcao Jr
jecel at merlintec.com
Thu Jul 18 23:06:44 UTC 2002
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
More information about the Squeak-dev
mailing list
|