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

David T. Lewis lewis at mail.msen.com
Wed Jan 14 04:45:05 UTC 2015


On Tue, Jan 13, 2015 at 04:05:05PM -0500, David T. Lewis 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.
> >
> 
> 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.

Confirmed.

If I trace a 32-bit image that is running on Cog and set the image format
number of the traced 64-bit image to 68003 rather than 68002, then the
resulting 64-bit image can be opened by a squeak64 interpreter VM. And BTW
the image trace runs much faster using Cog.

Tracing that 64-bit image back to 32-bits still requires that the traced
32-bit image be opened first with an interpreter VM, after which it can
be saved and run from a Cog VM. I do not know the reason for this, but
I expect that it is a different issue than the Float word ordering issue
discussed here.

Dave



More information about the Vm-dev mailing list