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@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@rowledge.org tim@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@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SG: Show Garbage