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)