Re: [Vm-dev] About 32bits LargeInt plugin [was how the h**l do I generate a signed shift?]
2014-07-01 0:40 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolas,
Hi Eliot,
look how I did it in the 32bits LargInt variant:
if the 32-bit large int version passes all the tests why hasn't it replaced the byte one?
Yes, 32bits large int pass all tests. I use such modified VM exclusively. All the code is maintained at http://smalltalkhub.com/#!/~nice/NiceVMExperiments for classical VM and Cog. I have not tested anything on Spur yet, but do not expect major problem.
It works well as is, but I'd like some improvments: - Prevent byte-wise copy to be used in BigEndian processor - Provide accelerated primitives for byteAt: byteAt:put: operations (I don't remember how I implemented them currently, it's too long ago)
Hi Nicolas,
I remember now. Of course, the big change is in holding state internally to LargeIntegers in native platform word order. That's a big change. But merging the VM all the time is a pain. Why don't we do something like this:
1. add a VM define, e.g. NativeOrderedLargeIntegers that can be set via a VM generation option. This define will end up in interp.h.
2. split the LargeIntegersPlugin (like the ThreadedFFIPlugin is split) into the old one and the native one, with LargeIntegers.c simply pulling in one or the other depending on the define.
3. in positive32BitIntegerFor et al use
self cppIf: NativeOrderedLargeIntegers ifTrue: [...your code...] ifFalse: [...the existing code...]
4. adopt your image header flags code, and make the image munging code convert integers as required
Then you don't have to merge and when we want to make the change we can simply set the variable in the generation configurations.
Meanwhile I see I /do/ have to fix the existing plugin :-(
On Mon, Jun 30, 2014 at 4:45 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-07-01 0:40 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolas,
Hi Eliot,
look how I did it in the 32bits LargInt variant:
if the 32-bit large int version passes all the tests why hasn't it replaced the byte one?
Yes, 32bits large int pass all tests. I use such modified VM exclusively. All the code is maintained at http://smalltalkhub.com/#!/~nice/NiceVMExperiments for classical VM and Cog. I have not tested anything on Spur yet, but do not expect major problem.
It works well as is, but I'd like some improvments:
- Prevent byte-wise copy to be used in BigEndian processor
- Provide accelerated primitives for byteAt: byteAt:put: operations (I
don't remember how I implemented them currently, it's too long ago)
2014-07-02 17:13 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolas,
I remember now. Of course, the big change is in holding stateinternally to LargeIntegers in native platform word order. That's a big change. But merging the VM all the time is a pain. Why don't we do something like this:
- add a VM define, e.g. NativeOrderedLargeIntegers that can be set via a
VM generation option. This define will end up in interp.h.
- split the LargeIntegersPlugin (like the ThreadedFFIPlugin is split)
into the old one and the native one, with LargeIntegers.c simply pulling in one or the other depending on the define.
in positive32BitIntegerFor et al use
self cppIf: NativeOrderedLargeIntegers ifTrue: [...your code...] ifFalse: [...the existing code...]
adopt your image header flags code, and make the image munging code
convert integers as required
Then you don't have to merge and when we want to make the change we can simply set the variable in the generation configurations.
Meanwhile I see I /do/ have to fix the existing plugin :-(
That sounds right for the future.
I'm pretty sure there is currently a problem at least in large int div. Most of the 32bit version is using unsigned arithmetic, so it is much more robust. I may help updating the 8bits version using the exact same tricks, but it's only possible during late evenings or early nights, I'm fully booked.
Nicolas
On Mon, Jun 30, 2014 at 4:45 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-07-01 0:40 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolas,
Hi Eliot,
look how I did it in the 32bits LargInt variant:
if the 32-bit large int version passes all the tests why hasn't it replaced the byte one?
Yes, 32bits large int pass all tests. I use such modified VM exclusively. All the code is maintained at http://smalltalkhub.com/#!/~nice/NiceVMExperiments for classical VM and Cog. I have not tested anything on Spur yet, but do not expect major problem.
It works well as is, but I'd like some improvments:
- Prevent byte-wise copy to be used in BigEndian processor
- Provide accelerated primitives for byteAt: byteAt:put: operations (I
don't remember how I implemented them currently, it's too long ago)
-- best, Eliot
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Nicolas Cellier