[squeakdev] 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)
tim Rowledge
tim at rowledge.org
Sat May 8 22:25:35 UTC 2021
I had to modify Dave's code smidge because #raisedTo: etc get used in the printing of the results of theTranscript>showln: used in ... #raisedToInteger:, which confused things a smidge.
So, renamed to #testRaisedToInteger: 
On Mac 64bit
TOP LOOP 1 BITPROBE 32
INNER LOOP 4
TOP LOOP 4 BITPROBE 16
INNER LOOP 64
TOP LOOP 64 BITPROBE 8
INNER LOOP 16384
TOP LOOP 16384 BITPROBE 4
INNER LOOP 1073741824
TOP LOOP 1073741824 BITPROBE 2
INNER LOOP 4611686018427387904
TOP LOOP 4611686018427387904 BITPROBE 1
On Pi4 64bit
TOP LOOP 1 BITPROBE 32
INNER LOOP 4
TOP LOOP 4 BITPROBE 16
INNER LOOP 64
TOP LOOP 64 BITPROBE 8
INNER LOOP 16384
TOP LOOP 16384 BITPROBE 4
INNER LOOP 1073741824
TOP LOOP 1073741824 BITPROBE 2
INNER LOOP 0
TOP LOOP 0 BITPROBE 1
What we then see is that the Integer>>#digitMultiply:neg: primitive is failing; commenting out the prim gets us the correct answer.
However, to make like that bit more amusing,
`SmallInteger maxVal squared`
gives the same answer on both systems (with the prim enabled on Pi 4) so it isn't simply that the largeint plugin is broken overall.
If I try 16r80000000 squared I *usually* get 0 but once or twice get 4611686018427387904, so clearly something odd is going on. Given that this appears to be platform specific I have to start suspecting something in the ARM64 trampoline code.
tim

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult: A onebit brain with a parity error.
More information about the Squeakdev
mailing list
