<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-23 5:20 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Moving discussion back to vm-dev, as it may be of some general interest.<br>
<br>
On Tue, Jul 22, 2014 at 09:16:23AM -0700, Eliot Miranda wrote:<br>
> On Mon, Jul 21, 2014 at 5:35 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> > Hi Eliot,<br>
> ><br>
> > I want to check before I copy this update to the VMMaker repository - are<br>
> > you in agreement with using Nicolas' LargeIntegerPlugin? It seems fine to<br>
> > me, so I'll move it to VMM trunk if you agree.<br>
> ><br>
><br>
> Well, it is goodness. My concern is that it requires image changes to make<br>
> image code still function, but haven't had time to check it out. The issue<br>
> is that currently, large integers are in little endian order and code in<br>
> the image accesses bytes in large integers assuming that the bytes there-in<br>
> are in little endian order. For example see digitCompare: and digitAt:.<br>
> Now digitAt: is implemented as simply primitive 60, the standard at:<br>
> primitive. So on current VMs a big-endian large integer will /not/ be<br>
> correctly accessed via digitAt:.<br>
><br>
> Am I right?<br>
<br>
I do not have a big endian machine to check this, but my assumption is that<br>
since Squeak began on big endian machines and moved to little endian<br>
later, and since the LargeIntegersPlugin has been around for a long time,<br>
and since images migrated across big and little endian platforms without<br>
any apparent problem, then we probably do not have any endianness problems<br>
with the existing plugin.<br>
<br>
I wrote a few tests (and added them to trunk) to validate the digit access<br>
methods. These tests pass on my little endian PC with a Cog VM using the<br>
old plugin, and they also pass with Nicolas' new LargeIntegersPlugin with<br>
both the 32-bit and 64-bit image formats.<br>
<br>
Nicolas' updated plugin seems to be fully compatible with the original<br>
LargeIntegersPlugin, and it produces the expected results for all of the<br>
image formats and VMs that I am able to test. I cannot confirm this for<br>
a big endian platform, but I think that any errors on big endian box<br>
would be exposed by the unit tests.<br>
<br>
It looks good to me.<br>
<br>
Nicolas, any concerns or comments?<br>
<br>
Thanks,<br>
Dave<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">There are two versions of my work<br></div><div class="gmail_extra">- one using 32 bits digits which is my original work commented on my blog <a href="http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.html">http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.html</a> and following posts that you can find on MC repository <a href="http://smalltalkhub.com/mc/nice/NiceVMExperiments/main">http://smalltalkhub.com/mc/nice/NiceVMExperiments/main</a><br>
</div><div class="gmail_extra">- a backport of this work for 8 bit digits that I failed to commit due to zip bug, and that I sent as a change set<br></div><div class="gmail_extra">I didn't check, but presumably you integrated the last one for 8 bit digits.<br>
</div><div class="gmail_extra">So there should be no problem of endianness<br><br></div><div class="gmail_extra">Nicolas<br></div></div>