[Vm-dev] About 32bits LargeInt plugin [was how the h**l do I generate a signed shift?]

Eliot Miranda eliot.miranda at gmail.com
Wed Jul 2 15:13:33 UTC 2014


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 at gmail.com> wrote:

>
>
>
> 2014-07-01 0:40 GMT+02:00 Eliot Miranda <eliot.miranda at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140702/73aedbdd/attachment-0001.htm


More information about the Vm-dev mailing list