On Sat, May 08, 2021 at 03:25:35PM -0700, tim Rowledge wrote:
> 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.
> 


If the primitive is failing for 16r80000000 squared, then I wonder if we
may be looking at a signed/unsigned arithmetic problem somewhere in the
plugin.

  16r80000000 asRegister ==> a TwosComplementRegister with value -2147483648 (10000000000000000000000000000000) 

You are running a 32-bit VM on Pi, right? If so, then perhaps the
same failure is happening on other 32-bit VMs but nobody noticed it
until now?

Dave