I am using Squeak 3.11. I assume the same results apply to Squeak 4.4. If not, my apologies. 3) (2 << 128) ==> 680564733841876926926749214863536422912In Squeak if I evaluate: 1) ((2 << 256) bitAnd: (2 << 128)) ==> 0 2) ((2 << 256) bitAnd: (2 << 128)) class ==> SmallInteger 4) ((2 << 128) bitAnd: (2 << 128)) ==> 680564733841876926926749214863536422912 This all looks correct and I care because I need to do <bitAnd:> of some largePositiveIntegers.receiver's bits and those of the argument. Fail if the receiver or argument is greater than 32 bits. See Object documentation whatIsAPrimitive." <primitive: 14> self halt. "I ADDED THE HALT" ^ super bitAnd: anInteger (<LargePositiveInteger>>BitAnd:>) and this is what I see when I run the code; i.e. I hit the halt. So why have <LargePositiveInteger>>BitAnd:> method at all? Ditto for the other bit operations. Ralph Boland |
On Thu, 20 Jun 2013, Ralph Boland wrote:
> I am using Squeak 3.11. I assume the same results apply to Squeak 4.4. If not, my apologies. LargePositiveInteger >> #bitAnd: is not present in Squeak 4.4. > > In Squeak if I evaluate: > > 1) ((2 << 256) bitAnd: (2 << 128)) ==> 0 > 2) ((2 << 256) bitAnd: (2 << 128)) class ==> SmallInteger > 3) (2 << 128) ==> 680564733841876926926749214863536422912 > 4) ((2 << 128) bitAnd: (2 << 128)) ==> 680564733841876926926749214863536422912 > > This all looks correct and I care because I need to do <bitAnd:> of some largePositiveIntegers. > > But <LargePositiveInteger>>BitAnd:> is: > > "Primitive. Answer an Integer whose bits are the logical AND of the > receiver's bits and those of the argument. Fail if the receiver or argument > is greater than 32 bits. See Object documentation whatIsAPrimitive." > <primitive: 14> > self halt. "I ADDED THE HALT" > ^ super bitAnd: anInteger > > The way I see it <LargePositiveInteger>>BitAnd:> is always going to fail and thus invoke its super version > (<LargePositiveInteger>>BitAnd:>) and this is what I see when I run the code; i.e. I hit the halt. > > So why have <LargePositiveInteger>>BitAnd:> method at all? all LargePositiveIntegers which can be represented in 4 bytes, so all values up to 4294967295. In your image the following expression should use the primitive: 4294967295 bitAnd: 1 In this case the primitive should fail: 4294967296 bitAnd: 1 Levente > > Ditto for the other bit operations. > > Ralph Boland > > |
Note that some times ago, Andreas and Eliot have added primitives exploiting the ubiquitous possibility of performing 64 bits arithmetic in underlying C language with modern compilers. So a possible strategy would be to invoke <primitive: 34> from LargePositiveInteger and fall back to super if failed. That may speed up some operations on "Small" large integers, and will add a bit more delay for "Large" and negative Large integers. Up to you to peek a sufficiently recent VM and test...So there is also InterpreterPrimitives>>#primitiveBitAndLargeIntegers which works for positive integer receiver and arguments up to 64 bits and is currently connected to primitive 34 in both Interpreter and COG VM. 2013/6/21 Levente Uzonyi <[hidden email]>
|
And as a complement, primitive 14 which is connected to InterpreterPrimitives>>#primitiveBitAnd effectively works for positive receiver and argument up to 32 bits. Bear in mind that SmallInteger maxVal highBit = 30, so it did make sense to try up to 32 bits.2013/6/21 Nicolas Cellier <[hidden email]>
|
Free forum by Nabble | Edit this page |