On 29.08.2010, at 23:02, Eliot Miranda wrote:

On Sun, Aug 29, 2010 at 1:31 PM, Bert Freudenberg bert@freudenbergs.de wrote:

On 29.08.2010, at 22:22, Eliot Miranda wrote:

...

On Sun, Aug 29, 2010 at 12:56 PM, Ken G. Brown kbrown@mac.com wrote: Running a fresh Squeak4.2-10382-alpha on your latest 5.8b4.

Open image, do Save As new version. then quit. Attempt to open saved new version image on Squeak 4.2.4beta1U.app by dragging and dropping on VM, it does not open. Console message: 10/08/29 1:51:57 PM [0x0-0x2fe2fe].org.squeak.Squeak[8275] This interpreter (vers. 6502) cannot read image file (vers. 6505).

John's 5.8b4 is a Cog VM. Once an image is saved on Cog it will only run on a Cog VM.

cheers Eliot

I'm sure you mentioned it before, but where can I read about the image format changes?

Lazily I've yet to write this up. But I think the only change above and beyond support for the closure bytecodes (and not using BlockContext at all) is that image float order now depends on platform, so on x86 it is little-endian; this was forced by the JIT implementation of floating-point arithmetic (its hard to byte swap efficiently given the lack of sophistication of the code generator), and by my not wanting to waste cycles converting to/from big-endian byte order on image load/save or image segment export. Bit 1 of the image header flags word (which used to contain only the full screen flag) is 1 if the image's floats are little-endian. So the existing VMs would need to read and write this bit and either convert back to big-endian or copy the Cog VMs in keeping floats in platform-specific order. For me throwing performance away on each floating-point op on x86 is a heinous sin, so at least internally floats should be little-endian. The basicAt: & basicAt:put: primitives 38 & 39 need to be implemented to present floats as big endian to the image level.

There are other changes to the image header, using unused bits and fields to store Cog-specific info and it would be convenient if the standard VMs preserve these fields. But they don't prevent loading on a standard VM; IIRC only the float-order changes would cause errors running a Cog image on a closure-enabled Interpreter VM.

If people think this is important enough I could put together a change set for VMMaker that includes the relevant changes (to image load/save, floating-point arithmetic, image segment load/store and float at:/at:put:).

best Eliot

If it's really so easy to make the regular VM work with that image, couldn't we just do it and not even bump the format?

- Bert -

On 30.08.2010, at 03:17, Eliot Miranda wrote:

On Sun, Aug 29, 2010 at 3:35 PM, Bert Freudenberg bert@freudenbergs.de wrote:

On 29.08.2010, at 23:02, Eliot Miranda wrote:

...

On Sun, Aug 29, 2010 at 1:31 PM, Bert Freudenberg bert@freudenbergs.de wrote:

On 29.08.2010, at 22:22, Eliot Miranda wrote:

...

On Sun, Aug 29, 2010 at 12:56 PM, Ken G. Brown kbrown@mac.com wrote: Running a fresh Squeak4.2-10382-alpha on your latest 5.8b4.

Open image, do Save As new version. then quit. Attempt to open saved new version image on Squeak 4.2.4beta1U.app by dragging and dropping on VM, it does not open. Console message: 10/08/29 1:51:57 PM [0x0-0x2fe2fe].org.squeak.Squeak[8275] This interpreter (vers. 6502) cannot read image file (vers. 6505).

John's 5.8b4 is a Cog VM. Once an image is saved on Cog it will only run on a Cog VM.

cheers Eliot

I'm sure you mentioned it before, but where can I read about the image format changes?

Lazily I've yet to write this up. But I think the only change above and beyond support for the closure bytecodes (and not using BlockContext at all) is that image float order now depends on platform, so on x86 it is little-endian; this was forced by the JIT implementation of floating-point arithmetic (its hard to byte swap efficiently given the lack of sophistication of the code generator), and by my not wanting to waste cycles converting to/from big-endian byte order on image load/save or image segment export. Bit 1 of the image header flags word (which used to contain only the full screen flag) is 1 if the image's floats are little-endian. So the existing VMs would need to read and write this bit and either convert back to big-endian or copy the Cog VMs in keeping floats in platform-specific order. For me throwing performance away on each floating-point op on x86 is a heinous sin, so at least internally floats should be little-endian. The basicAt: & basicAt:put: primitives 38 & 39 need to be implemented to present floats as big endian to the image level.

There are other changes to the image header, using unused bits and fields to store Cog-specific info and it would be convenient if the standard VMs preserve these fields. But they don't prevent loading on a standard VM; IIRC only the float-order changes would cause errors running a Cog image on a closure-enabled Interpreter VM.

If people think this is important enough I could put together a change set for VMMaker that includes the relevant changes (to image load/save, floating-point arithmetic, image segment load/store and float at:/at:put:).

best Eliot

If it's really so easy to make the regular VM work with that image, couldn't we just do it and not even bump the format?

But reason for the change in image format number is not to distinguish the format of the file. The point is that the standard interpreter can run both BlockContext and BlockClosure images but Cog can only run BlockClosure images. So the bump of image format is to mark images that use only BlockClosures. So for me its definitely the right thing to do to have a different image version. If Cog could run images containing BlockContext blocks it would be different, but it can't.

cheers, Eliot

Well, we had intended some more cleanups to be done when we decide to change the image format.

In any case it would be nice to be able to open cog-saved images in a regular VM - I'm thinking of the ARM systems that might not get a Cog version soon.

- Bert -