Animorphic ST (Strongtalk) released!

Tim Rowledge tim at sumeru.stanford.edu
Thu Jul 18 17:51:49 UTC 2002


Dan Ingalls <Dan at SqueakLand.org> is claimed by the authorities to have written:

> So, what happens when you start it?
> 
> 	It starts to run the first method which is not translated
> 		so it runs the interpreter
> 	Things lumber along for a while this way until something
> 		notices the umpteenth execution of the same method
> 		and asks for it to be compiled
> 	Now the compiler starts to run but, of course, it's not
> 		translated so it starts kind of slow
> 	Along the way the compiler hits some inner loops and these
> 		need in turn to be translated
> 	Gradually the compiler speeds up until it runs as fast
> 		as StrongTalk, and what more could we ask for?
> 
> This is, of course recursive but, as long as the system supports both interpreted and translated code, I don't think it's a problem as long as you recognize three states of a method:
> 
> 	Interpreted
> 	Being translated
> 	Translated
Some time ago I suggested a similar possible approach to allow writing
of the translator in Smalltalk so that it would be more intelligable,
manipulable etc. It's not a particularly original idea of mine, being
loosely based on my (probably poor) understanding of Ian P's doctoral
thesis and vague discussions before then with LPD, Schiffman,
Baker, Eliot M, etc.

The good news is that surprisingly little would need to change in the VM
code we already have. An extra oop in compiled methods (or maybe in a
lookup cache, who knows) to point to the translated chunk if it exists,
some way to queue up an untranslated method for processing, a way to set
the translated oop once the translation has finished. The current
interpreter would merrily keep going and the translator would run as a
suitable priority process. Recognising the middle state of 'in
translation' would be a small optimisation to allow for dumping
the translation of a method that had been changed since it was queued
up.

I think you could even fake up the support framework by making the
system allow for the 'translated' methods to be just the normal
bytecodes, thus saving having to write the actual translator till later.
It would provide nice confirmation of the functionality being reasonable
quite quickly.

It would possibly be reasonable to allow the image to be saved with
translated methods intact so long as a check were plausible to drop them
if the image started on a different machine.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Any given program will expand to fill available memory.




More information about the Squeak-dev mailing list