[Vm-dev] Re: [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

[Eliot Miranda]

On Sun, Aug 29, 2010 at 1:31 PM, Bert Freudenberg <bert at 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 at 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



> - Bert -
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100829/de45e4bc/attachment.htm