Don't be nice if this big company sponsor Squeak ?
Dan at SqueakLand.org
Tue Nov 14 16:49:07 UTC 2006
Sorry, I'm not always up to date on my Squeak email...
>On Nov 14, 2006, at 10:36 , Michael Rueger wrote:
>>Edgar J. De Cleene wrote:
>>>Any comments ?
>>Wonder where this comes from ;-)
>>See the people page under the letter "I" :-)
and Bert replied...
>Actually I think this started way before Dan went to Sun.
Yes, it did, but the name is no accident. Squeak's compactness and simplicity and the write-in-itself-then-translate-to-C-for-deployment approach inspired Nik Shaylor's design that was carried out by the early team.
>Sounds impressive though:
>"The static footprint of the core system (interpreter, a RAM garbage collector, an non-volatile memory garbage collector), compiled from C, is 25 kB on x86. The minimum runtime footprint in RAM is 520 bytes for the Java heap and 532 bytes for native stack and data (on x86)."
These are the stats for the early version; the current implementation that supports the SPOTs is somewhat larger, but it has lots of other (cool) features, most especially all the mechanism for wireless mesh networking. There's lots more about that in various papers about the SPOTs.
An especially interesting aspect of the current challenge for Squawk is performance. In the world of SPOTs, the most important figure of merit is power, so instead of the speed issue (nanoseconds per bytecode) you have a power issue (picojoules per bytecode). And space is also an issue, of course, so you get these interesting strategies such as compiling ahead of time, then compressing for space, and storing in flash. Here the analogy to JIT is decompressing out of flash into the RAM working set. Which is better can be a matter of which uses less energy!
I did oversee the Squawk project for about six months after arriving at Sun and before starting my current project, but all the work was done by the other team members listed on the Sun site.
More information about the Squeak-dev