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

Eliot Miranda eliot.miranda at gmail.com
Mon Aug 30 01:17:19 UTC 2010


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


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


More information about the Squeak-dev mailing list