[squeak-dev] 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

tim Rowledge tim at rowledge.org
Sun May 9 17:56:47 UTC 2021

> On 2021-05-09, at 7:31 AM, David T. Lewis <lewis at mail.msen.com> wrote:

> 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.

Ah, but that is the extra-weird bit. It *sometimes* gives the right answer. The only thing I can think of that could explain that & that might be ARM64 code specific is something to do with the address of the LPI, which obviously is sometihng that varies with each test. If there is some code expecting base addresses to always match some requirement and that is not always being met, subsequent code might be reading the wrong values. 

Another possibility is that the compiled result of the LI plugin has a bug; it's not like C compilers never get it wrong.

Another possibility must be that I screwed up somewhere and the 'correct' result I saw was not actually with the prim enabled - but I'm fairly sure I did that in a different image anyway. Grr.

And now I do more testing, and I haven't yet got the right answer again for 16r80000000 squared. 
16r80000001 squared always seems to be ok. 16r[9ABCDEF]0000000 squared always seems to be ok. And 16r[7654321]0000000 squared always seems to be right.

Also 16r40000000 squared * 4 seems always ok. So we're rather pointed to some peculiarity of the 16r80000000 bit-pattern? My brian hurts.

tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

More information about the Squeak-dev mailing list