[Vm-dev] Re: VM Maker: VMMaker-dtl.189.mcz

David T. Lewis lewis at mail.msen.com
Wed Oct 6 15:10:22 UTC 2010


Yes, that is the intent. It should help with the transition to Cog in
several ways:

1) It should now be safe to use Cog on your favorite image, even if you
think you might want to go back to the old image format.

2) If you save an image from a Cog VM in the newer image format (6505)
and distribute it to folks who may not be able to run Cog for one reason
or another, it will now be possible for them to load that image back
into a traditional VM.

3) If you want to use Cog to build an an image for wide distribution (the
upcoming Squeak 4.2 release for example) and you want to distribute the
image in the older image format (probably a prudent choice for the next
round of releases), you can now load and save the image one time in a
traditional VM, and the image will be put back into 6504 format.

Caveat: I just finished doing this last night and it is only lightly
tested.  I don't anticipate any problems, but you never know ;)

The traditional VM should still run pre-closure images (format 6502)
and will continue to save them in pre-closure 6502 format. Eliot
set this up so that the conversion from 6502 pre-closure format to
6504 format happens automagically, but only when you first actually
compile something with closure support. But I guess this should be
tested to make sure I did not break it ;)

Dave

On Wed, Oct 06, 2010 at 06:53:48AM -0700, Bert Freudenberg wrote:
> 
> Yay!
> 
> I'm wondering wether this can help make the transition to Cog be less painful. Does anyone have ideas in that direction? E.g., there still is need for the interpreter, to run pre-closure images. Many production systems use those (e.g the currently deployed Etoys releases), we don't want a Squeak VM update break them.
> 
> - Bert -
> 
> On 06.10.2010, at 05:02, Igor Stasenko wrote:
> 
> > 
> > This is really nice, because it will cut the number of development
> > images by half!
> > Thanks, David.
> > 
> > On 6 October 2010 07:32, David T. Lewis <lewis at mail.msen.com> wrote:
> >> 
> >> This could stand a bit of testing before folks rely on it too
> >> heavily, but it should permit Cog to be used for developing images
> >> that may later need to be loaded into a standard VM.  I have
> >> loaded an image saved from Cog (format 6505) into a standard VM,
> >> saved it in the older 6504 format, then read that image back into
> >> a Cog VM. There are no obvious problems, and the Float values
> >> are preserved as expected.
> >> 
> >> Eliot, the changes are attached.
> >> 
> >> Dave
> >> 
> >> On Wed, Oct 06, 2010 at 06:17:56AM +0000, squeak-dev-noreply at lists.squeakfoundation.org wrote:
> >>> Dave Lewis uploaded a new version of VMMaker to project VM Maker:
> >>> http://www.squeaksource.com/VMMaker/VMMaker-dtl.189.mcz
> >>> 
> >>> ==================== Summary ====================
> >>> 
> >>> Name: VMMaker-dtl.189
> >>> Author: dtl
> >>> Time: 6 October 2010, 12:17:37 pm
> >>> UUID: 29192b6e-491d-4bc6-a209-5ba1c8625da0
> >>> Ancestors: VMMaker-dtl.188
> >>> 
> >>> VMMaker 4.3.3
> >>> 
> >>> Allow a standard interpreter VM to load and run an image that was saved from a Cog or StackInterpreter VM. On image load, the storage format of Float objects is returned to normalized word ordering (different from platform word order for little endian platforms) and unrecognized header flags are cleared. The image will be saved in standard interpreter format (image format 6504 for a 32-bit image), which may subsequently be loaded by a Cog or StackInterpreter VM.
> >>> 
> >>> Works for 32-bit Cog images (image format 6505) on both 32-bit and 64-bit host (compile -m32 or -m64). Support for 64-bit image formats is not yet implemented, see comment in #normalizeFloatOrderingInImage.
> >> 
> >> 
> > 
> > 
> > 
> > -- 
> > Best regards,
> > Igor Stasenko AKA sig.
> 


More information about the Vm-dev mailing list