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

Eliot Miranda eliot.miranda at gmail.com
Tue Jan 13 18:16:51 UTC 2015


On Tue, Jan 13, 2015 at 8:59 AM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

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

And  Float>>basicAt:put: uses primitive 39.  I had to add these to Cog so
that the VM was free for the underlying platform to choose the most
efficient representation.  It is a shame that we're saddled with a
bug-endian order since large integers are little endian.  But don't sweat
the petty stuff, pet the sweaty stuff...
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150113/ca62d70d/attachment.htm


More information about the Vm-dev mailing list