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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jul 2 15:46:30 UTC 2014


2014-07-02 17:13 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
> 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 :-(
>
>
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 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/d94b012d/attachment-0001.htm


More information about the Vm-dev mailing list