The Crusoe and the future of Dynabook?

agree at carltonfields.com agree at carltonfields.com
Fri Jan 21 22:57:26 UTC 2000


> You would need to replace the current interpreter with a > "code morpher" for
> this to be the case. Of course, no one is keeping you from > doing a Jitter 4 or
> a Self-style adaptive compilation system/HotSpot right now > and it would make
> Squeak scream on the current hardware (just one, most > likely...). I am guessing
> that the "Crusoe Squeak code morpher" would be harder to > develop than the
> latter options. Of course, if someone was paying for it then > it might happen
> first.

Forgive me for reraising an old sore, but is there any reason why we should expect a JIT VM to be machine-independent?  Why can't there be some hook to facilitate local compilation/optimization of bytecodes when a JITTER present, and to revert to "traditional" interpretation where it is not?  (All this, provided, of course, that the JITTER be specified to provide functionality IDENTICAL to that of the VM).

Apple managed this in a nearly seamless fashion when they segued from 680x0 to PowerPC architectures by using "FAT" binaries (and 680x0 interpretation for a times, but I am not here suggesting that latter approach).  Each System 7 machine knew whether it was running on a PC or 68K and would execute the appropriate binary.  We could do likewise for Squeak.  Each VM knows what machine/OS on which it is running, and what kind of binary it is expecting.  If a CompiledMethod has a fork of appropriate type, that code can be loaded and run, otherwise a decision whether to compile or interpret can be made (and if to compile, whether to optimize or not).  An image containing foreign CompiledMethods would not execute the foreign methods, and those foreign forks could probably be set to be GC'd and freed in some manner.  There are some more sophisticated methods that could also work.

Designed right, we might be able to get Squeak screaming on many platforms, without cost or degradation on current platforms.  It seems that the infrastructure for native JIT can be machine-independent, with only the native compilers/optimizers can all be written in machine-dependent Slang.

I guess the big question is whether such an approach to native compilation/optimization would be "enough," or that much better than more machine-dependent solutions.  Frankly, I defer to those who have likely already considered these routes.

I am game to try, however, if this seems to others to be a worthwhile exercise.

As an aside, has anyone surveyed which machine/OS presently has the largest Squeak user base?





More information about the Squeak-dev mailing list