[Vm-dev] About primitiveBitAnd / Or / Xor

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Apr 1 20:53:13 UTC 2015


2015-04-01 0:06 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

>
>
>
> On Tue, Mar 17, 2015 at 2:38 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>> Hi again,
>> I've noticed the COG code currently branches on objectMemory wordSize = 8
>> condition,
>> to either load self positive64BitValueOf: integerArgument.
>> or to load self positive32BitValueOf: integerArgument.
>>
>> Of course, this could be resolved to a single
>>     integerArgument := self positiveMachineIntegerValueOf: integerArgument
>> which will care of the branch by itself...
>> That's what I did.
>>
>> But maybe the intention was rather to deal with signed64BitValueOf in the
>> 64 bit branch like what was done to primitiveBitShift?
>>
>
> Right.  I want to avoid the call altogether in that case.
>
>
>
Hi Eliot,
You probably mean that it's already eliminated in JIT and/or when
interpreting special send bytecode.
This occurs only when receiver and argument are both SmallInteger.

So, simulation apart, the remaining cases handled by the primitive are when
one of receiver or argument is a Large (presumably receiver is small with
current usage at image side), that is an
- int between: SmallInteger maxVal+1 and: 1<<32-1 for 32 bits
- int between: SmallInteger maxVal+1 and: 1<<64-1 for Spur64 if we use
positiveMachineIntegerValueOf:
- int between: SmallInteger maxVal+1 and: 1<<63-1, or between: (1<<63)
negated and: SmallInteger minVal-1 if we use signed64BitValueOf:

Do we want to extend the primitive up to 64bits but only for positive
receiver and argument, or to signed large ints for Spur64?

 Nicolas

Of course, all this is assuming that the machine uses a 2-complement
>> implementation, otherwise it won't match the Smalltalk semantic.
>> That's not so rare ;) - but theoretically not fully portable - contrarily
>> to actual strategy which is fully portable.
>> Since other parts of the VM also rely on such specific, maybe we can
>> trade a little portability tribute for the sake of speed.
>>
>
> Yes, for me trying to make the VM portable to non-2's compliment systems
> isn't worth it.  I remember that there's a fair bit of code in HPS that
> tries to cope with systems that don't have 8-bit bytes.  Again pointless.
> The world is more homogenous now than it was in the time of PDP-10s, and
> that's a good thing.  If some feature isn't exercised it atrophies and
> becomes a hindrance.
>
>
>
>>
>> Thoughts?
>>
>
>> Nicolas
>>
>>
>
>
> --
> best,
> Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150401/d548e66d/attachment.htm


More information about the Vm-dev mailing list