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

Bert Freudenberg bert at freudenbergs.de
Tue Jan 13 16:59:17 UTC 2015


> 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.

- Bert -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4115 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150113/31aa734b/smime.bin


More information about the Vm-dev mailing list