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?
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.
Thoughts?
Nicolas
On Tue, Mar 17, 2015 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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.
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
2015-04-01 0:06 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Mar 17, 2015 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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
vm-dev@lists.squeakfoundation.org