[Vm-dev] Special Objects Array question
eliot.miranda at gmail.com
Tue Nov 2 17:34:03 UTC 2010
On Tue, Nov 2, 2010 at 3:50 AM, Gabriel Hernán Barbuto
<gbarbuto at gmail.com>wrote:
> I am looking at MicroSqueak and trying to make it work in a new image.
> I run MicroSqueak in a new VM and it works. What is a bit odd is that
> MicroSqueak has a different class hierarchy for String. It doesn't
> know about ByteString nor WideString and the String class in
> MicroSqueak has a different format than the one in recent images.
> How is it possible that a MicroSqueak generated image runs on the
> recent VMs? The special objects array that MicroSqueak creates is
> different. For example, at index 7 MicroSqueak put its own version of
> String instead of ByteString. I have tried it on Mac OS X on the
> Squeak 4.2.5b1 VM and on Windows on the 4.0.2 VM.
> My guess is that it works because MicroSqueak String has the same
> structure as ByteString in current images. So the VM does not notice
> that it is working with a different object.
Exactly. In Smalltalk-80 v2.0 there was no wide string support so String
was the concrete string class with 8-bit elements. Now we have wide string
support and hence ByteSymbol ByteString WideSymbol and WideString. The VM
requires that specialObjectsArray at: 7 is an 8-bit string class which is
ByteString in contemporary Squeaks and String in older Squeaks.
Remember the major goal of the MicroSqueak work is to produce a kernel image
that can bootstrap a contemporary Squeak image. So it is important to bring
MicroSqueak up-to-date, and make it's classes match the current system. For
example, its use of System in place of SmalltalkImage and SystemDIctionary
as well as its use of String in place of ByteString and String makes sense
if the goal is as small an image as possible but doesn't make sense if the
goal is bootstrapping current images. So please update these areas of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev