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@mail.msen.com wrote:
Hi Eliot,
I want to check before I copy this update to the VMMaker repository - are you in agreement with using Nicolas' LargeIntegerPlugin? It seems fine to 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 make image code still function, but haven't had time to check it out. The issue is that currently, large integers are in little endian order and code in the image accesses bytes in large integers assuming that the bytes there-in 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?
Thanks, Dave
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.
There is, or at least was, code to byteswap byte objects at image load time. Not in a good spot to check right now. I think it went Check endian is as was Swap all words if needed. Swap back contents of byte objects.
Or something like that.
/tim {insert witticism here}
On Tue, Jul 22, 2014 at 08:55:49PM -0700, tim Rowledge wrote:
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.
There is, or at least was, code to byteswap byte objects at image load time. Not in a good spot to check right now. I think it went Check endian is as was Swap all words if needed. Swap back contents of byte objects.
Or something like that.
/tim
Judging by the author credited in the method comment, I suspect that you are probably right ;)
Interpreter>>reverseBytesInImage "Byte-swap all words in memory after reading in the entire image file with bulk read. Contributed by Tim Rowledge."
"First, byte-swap every word in the image. This fixes objects headers." objectMemory reverseBytesFrom: objectMemory startOfMemory to: objectMemory getEndOfMemory.
"Second, return the bytes of bytes-type objects to their orginal order." self byteSwapByteObjects.
Wholly khao. That would have to be eighteen years ago. That would originally have run on a 40MHz ARM 7 machine with maybe 4Mb ram. As I recall I was sharing an office - actually a tiny fraction of an office cubicle - with John Maloney's wife Roxie at the time. How time flies.
/tim {insert witticism here}
On Jul 22, 2014, at 21:59, "David T. Lewis" lewis@mail.msen.com wrote:
On Tue, Jul 22, 2014 at 08:55:49PM -0700, tim Rowledge wrote:
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.
There is, or at least was, code to byteswap byte objects at image load time. Not in a good spot to check right now. I think it went Check endian is as was Swap all words if needed. Swap back contents of byte objects.
Or something like that.
/tim
Judging by the author credited in the method comment, I suspect that you are probably right ;)
Interpreter>>reverseBytesInImage "Byte-swap all words in memory after reading in the entire image file with bulk read. Contributed by Tim Rowledge."
"First, byte-swap every word in the image. This fixes objects headers." objectMemory reverseBytesFrom: objectMemory startOfMemory to: objectMemory getEndOfMemory.
"Second, return the bytes of bytes-type objects to their orginal order." self byteSwapByteObjects.
2014-07-23 5:20 GMT+02:00 David T. Lewis lewis@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@mail.msen.com
wrote:
Hi Eliot,
I want to check before I copy this update to the VMMaker repository -
are
you in agreement with using Nicolas' LargeIntegerPlugin? It seems fine
to
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
make
image code still function, but haven't had time to check it out. The
issue
is that currently, large integers are in little endian order and code in the image accesses bytes in large integers assuming that the bytes
there-in
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?
Thanks, Dave
There are two versions of my work - one using 32 bits digits which is my original work commented on my blog http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.h... and following posts that you can find on MC repository http://smalltalkhub.com/mc/nice/NiceVMExperiments/main - 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
Nicolas
On Wed, Jul 23, 2014 at 11:44:42AM +0200, Nicolas Cellier wrote:
2014-07-23 5:20 GMT+02:00 David T. Lewis lewis@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@mail.msen.com
wrote:
Hi Eliot,
I want to check before I copy this update to the VMMaker repository -
are
you in agreement with using Nicolas' LargeIntegerPlugin? It seems fine
to
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
make
image code still function, but haven't had time to check it out. The
issue
is that currently, large integers are in little endian order and code in the image accesses bytes in large integers assuming that the bytes
there-in
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?
Thanks, Dave
There are two versions of my work
- one using 32 bits digits which is my original work commented on my blog
http://smallissimo.blogspot.fr/2012/12/accelerating-largeinteger-in-squeak.h... and following posts that you can find on MC repository http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
- 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
Nicolas,
Yes, I integrated the second one for 8 bit digits. I will go ahead and move it into the VMMaker repository, and commit the ./src files for trunk SVN.
Thank you!
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Nicolas Cellier -
tim Rowledge