Detecting Cog or Byte order

 
I discovered a bug in cobalt today due to the float-endianness
of ImageSegments made in cog vs interpreter:

http://croquet-src-01.oit.duke.edu/mantis/view.php?id=503

Is there a way to detect the platform endianness, so we can, in
the future, add metadata about that to ImageSegments, and then
byte-swap them if needed?

Failing that, I guess we could add a constant float to the image
segment, and test whether it unpacks as byte-swapped or not

-------------------

Since cobalt mantis doesn't allow anonymous viewers (grr), here
is the text of the issue:

Summary  0000503: Cannot connect an Interpreter VM with a Cog VM
due to float endianness
Description  A Cog VM sends image segments with a byte-swapped
floating-point numbers compared to the Interpreter VM. When
unpacking a sync from a cog vm on an interpreter VM, this
usually results in a "Past message encountered" error

--
Matthew Fulmer (a.k.a. Tapple)

 
On Sat, Apr 16, 2011 at 05:34:59PM -0400, Matthew Fulmer wrote:
Thinking about it, I guess this should be fixed in the
ImageSegment post-loader, rather than in cobalt

--
Matthew Fulmer (a.k.a. Tapple)

 

ImageSegment >> endianness
    "Return which endian kind the incoming segment came from"

    ^ (segment first bitShift: -24) asCharacter == $d ifTrue: [#big] ifFalse: [#little]


Check senders of #endianness, mostly in methods like #startUpFrom:

Cheers

Mariano




--
Mariano
http://marianopeck.wordpress.com

 
On Sat, Apr 16, 2011 at 05:34:59PM -0400, Matthew Fulmer wrote:
"Smalltalk isLittleEndian"

Floats are word-reversed to put them in native platform word order
if and only if Smalltalk isLittleEndian and the image format number
is 6505 or 68003 (where 68003 is a hypothetical 64 bit Cog image).

Details of image format identification are documented in classes
ImageFormat and ImageFormatTest, which you can load from SqS/VMMaker
package "ImageFormat". You can think of the low order bit of the image
format number as the "floats in native word order" bit.

The interpreter VM ("trunk" VMMaker in SqueakSource) has a primitive
#primitiveImageFormatVersion for identifying the image format number
of the running image (this should probably be added to Cog also (note
to self - doIt).

In the interpreter VM, the float word order handling is in
#normalizeFloatOrderingInImage. We probably need something similar
for handling image segments.

I don't think that image segments have a "format number", so it may be
best in image segments to enforce a convention of always storing floats
in "legacy" word ordering, i.e. the convention for images prior to Cog.

Dave