[Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

[David T. Lewis]

>
>> On 13.01.2015, at 17:30, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>>> On 13.01.2015, at 03:29, David T. Lewis <lewis at mail.msen.com> wrote:
>>>>
>>>> I was driving home this afternoon and it popped into my head. I am
>>>> quite
>>>> sure the the problem is due to the change in floating point word
>>>> ordering
>>>> in the Cog image format (6505). If you trace an image that is running
>>>> under
>>>> a Cog VM on a little endian host, the Float objects will require
>>>> special
>>>> handling to put them back into the original canonical format (which is
>>>> not
>>>> the native machine order on a little endian machine).
>>>
>>> But the word accessors in Float handle that I thought? Or don't they,
>>> in
>>> 64 bits?
>>>
>>> - Bert -
>>>
>>
>> This issue would be that the in-memory representation of the float objects
>> (which contain two 4-byte words of data) have the words reversed (i.e. put
>> into machine word order) when running on Cog on a little endian machine.
>> That in-memory representation is the thing being written out to disk
>> during the trace. The tracer thinks that it is writing objects with
>> fields
>> in the original (format 6504, non-Cog) format, and it does not know when
>> it encounters a Float object that it needs to swap the data words. The
>> reason that it does not know this is that nobody has implemented it yet
>> :-)
>>
>> Dave
>
> I know that. I also know that Float>>basicAt: uses primitive 38 which is
> designed to always answer the words of a Float as if they were stored in
> big-endian order, no matter what the actual memory order is.
>

I think the primitive handles processor word ordering, but does not know
about the float word ordering convention in Cog. In the interpreter VM, we
check the "cog bit" in the image format number at image load time, and
undo the float word ordering if the bit is set and if we are on a little
endian machine.

Come to think of it, I'll bet that just setting the cog bit in the traced
image header would be sufficient to address this. The 64-bit image would
be waking up in an interpreter VM, so it should hopefully notice the cog
bit and do the necessary Float word reordering. I'll have to give that a
try when I get home.

Dave