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

Vanessa Freudenberg vanessa at codefrau.net
Mon May 10 15:45:55 UTC 2021


I think we really ought to move the discussion over to the experts at
vm-dev. CC’ed.

–Vanessa–

On Mon, May 10, 2021 at 03:55 Bruce O'Neel <bruce.oneel at pckswarms.ch> wrote:

> Hi,
>
> So, um, kind of good news but maybe not.
>
> So I built a collection of different VMs on ARM64 and the most recent
> build is below.  The stack VM gives the right answer, the cog one not.
>  The dates are the dates of the most recent commit from the git repository.
>
> 2020/03/24 - Cog VM does not build, stack vm builds with the right answer.
> 2021/01/09 - Both stack and cog VMs build.  Stack VM gives the right
> answer.
> 2021/03/24 - Both stack and cog VMs build.  Stack VM gives the right
> answer.
>
> All of this on a Ubuntu 18.04 based system with Gcc 7.5.0 on an NVIDIA
> Jetson Nano which has A57 cores.
>
> I also in all cases with the cog VMs I tested the debug build as well in
> hopes that it was a GCC optimization problem, but, alas, no luck there.
>
> Tim, is it possible to try a stack build and see if that gives the correct
> answer for you?
>
> Thanks.
>
> bruce
>
>
>
>
>
> [image: image.png]
>
>
>
> *09 May 2021 19:56 tim Rowledge <tim at rowledge.org <tim at rowledge.org>>
> wrote:*
>
>
>
> > On 2021-05-09, at 7:31 AM, David T. Lewis 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
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: SG: Show Garbage
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210510/836cd386/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 306507 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210510/836cd386/attachment-0001.png>


More information about the Vm-dev mailing list