[Vm-dev] Status of LargeIntegersPlugin
ncellier at ifrance.com
Wed Jul 23 09:44:42 UTC 2014
2014-07-23 5:20 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
> Moving discussion back to vm-dev, as it may be of some general interest.
> On Tue, Jul 22, 2014 at 09:16:23AM -0700, Eliot Miranda wrote:
> > On Mon, Jul 21, 2014 at 5:35 PM, David T. Lewis <lewis at mail.msen.com>
> > > Hi Eliot,
> > >
> > > I want to check before I copy this update to the VMMaker repository -
> > > you in agreement with using Nicolas' LargeIntegerPlugin? It seems fine
> > > me, so I'll move it to VMM trunk if you agree.
> > >
> > Well, it is goodness. My concern is that it requires image changes to
> > image code still function, but haven't had time to check it out. The
> > is that currently, large integers are in little endian order and code in
> > the image accesses bytes in large integers assuming that the bytes
> > are in little endian order. For example see digitCompare: and digitAt:.
> > Now digitAt: is implemented as simply primitive 60, the standard at:
> > primitive. So on current VMs a big-endian large integer will /not/ be
> > correctly accessed via digitAt:.
> > Am I right?
> I do not have a big endian machine to check this, but my assumption is that
> since Squeak began on big endian machines and moved to little endian
> later, and since the LargeIntegersPlugin has been around for a long time,
> and since images migrated across big and little endian platforms without
> any apparent problem, then we probably do not have any endianness problems
> with the existing plugin.
> I wrote a few tests (and added them to trunk) to validate the digit access
> methods. These tests pass on my little endian PC with a Cog VM using the
> old plugin, and they also pass with Nicolas' new LargeIntegersPlugin with
> both the 32-bit and 64-bit image formats.
> Nicolas' updated plugin seems to be fully compatible with the original
> LargeIntegersPlugin, and it produces the expected results for all of the
> image formats and VMs that I am able to test. I cannot confirm this for
> a big endian platform, but I think that any errors on big endian box
> would be exposed by the unit tests.
> It looks good to me.
> Nicolas, any concerns or comments?
There are two versions of my work
- one using 32 bits digits which is my original work commented on my blog
and following posts that you can find on MC repository
- 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
I didn't check, but presumably you integrated the last one for 8 bit digits.
So there should be no problem of endianness
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev