<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 8:59 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><br>
> On 13.01.2015, at 17:30, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
>> On 13.01.2015, at 03:29, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
>>><br>
>>> I was driving home this afternoon and it popped into my head. I am quite<br>
>>> sure the the problem is due to the change in floating point word<br>
>>> ordering<br>
>>> in the Cog image format (6505). If you trace an image that is running<br>
>>> under<br>
>>> a Cog VM on a little endian host, the Float objects will require special<br>
>>> handling to put them back into the original canonical format (which is<br>
>>> not<br>
>>> the native machine order on a little endian machine).<br>
>><br>
>> But the word accessors in Float handle that I thought? Or don't they, in<br>
>> 64 bits?<br>
>><br>
>> - Bert -<br>
>><br>
><br>
> This issue would be that the in-memory representation of the float objects<br>
> (which contain two 4-byte words of data) have the words reversed (i.e. put<br>
> into machine word order) when running on Cog on a little endian machine.<br>
> That in-memory representation is the thing being written out to disk<br>
> during the trace. The tracer thinks that it is writing objects with fields<br>
> in the original (format 6504, non-Cog) format, and it does not know when<br>
> it encounters a Float object that it needs to swap the data words. The<br>
> reason that it does not know this is that nobody has implemented it yet<br>
> :-)<br>
><br>
> Dave<br>
<br>
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.<br></blockquote><div><br></div><div>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...</div></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>