Smalltalk › Squeak › Squeak - Dev

how to determine available RAM?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Chris Muller-3

how to determine available RAM?

I have an old method from 2014 which could calculate the maximum
*addressable* RAM for 32-bit images. First it checked for the -memory
or -mmap arguments (are these still supported?) and used them if
specified, otherwise, it default to these hard-coded numbers:

isRunningSpur? -> 3.8GB
else Win32? -> 500MB
else -> 1GB

But now with 64-bit, the addressable exceeds the available RAM of most
machines. What is that max addressable BTW, 64GB?

Also, what about taking into account what the OS believes it has
*remaining*? Can it be done within the image or would I have to call
out to "free" via OSProcess or something..?

Thanks for any tips.

- Chris

timrowledge

2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

I was just about to say something about Chris'question and tried

2 raisedTo: 63

in a Workspace. I was a little surprised to see '0' returned.

On my Mac 64 I get the right answer. On the Pi I get the right(ish) answer if I substitute 2.0. To make things weirder if I debug, the end value of 'result' in Number>>#raisedToInteger: is correct. The value of 'stack top' in its sender #raisedTo: is the same correct value.

Gronk? It's clearly not a problem with printing the value since I see the correct value. If I try
(2 raisedTo: 63) / 64.0
to check what number is actually there... I get 0. Implying there is really 0. Debug it and.. yup 0. What? It looks like somewhere the LPI instance is getting mishandled but where?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CSD: Charge Surreptitiously to DOE

Tony Garnock-Jones-5

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

On 5/7/21 1:33 AM, tim Rowledge wrote:
> 2 raisedTo: 63
> in a Workspace. I was a little surprised to see '0' returned.

Eek!

I don't see this BTW. Here's what I get:

2 raisedTo: 63 "9223372036854775808"

Output from uname -a:

Linux zip 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64
GNU/Linux

Output from squeak -version:

5.0-202003021730 Tue Mar 3 08:27:37 UTC 2020 clang [Production Spur
64-bit VM]
CoInterpreter VMMaker.oscog-nice.2715 uuid:
78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96
Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Linux travis-job-16fcd698-43db-40d8-82c2-9f02c4a1c566 4.15.0-1028-gcp
#29~16.04.1-Ubuntu SMP Tue Feb 12 16:31:10 UTC 2019 x86_64 x86_64 x86_64
GNU/Linux
plugin path:
/opt/Squeak/Squeak6.0alpha-19905-64bit-202003021730-Linux/bin/ [default:
/opt/Squeak/Squeak6.0alpha-19905-64bit-202003021730-Linux/bin/]

Finally, from "About Squeak" in the image:

Image
-----
/home/tonyg/src/Squeak/squeak.image
Squeak6.0alpha
latest update: #20329
Current Change Set: Unnamed
Image format 68021 (64 bit)
Preferred bytecode set: SistaV1

Virtual Machine
---------------
squeak
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives
VMMaker.oscog-nice.2715]
Unix built on Mar 3 2020 08:27:09 Compiler: 4.2.1 Compatible Clang
7.0.0 (tags/RELEASE_700/final)
platform sources revision VM: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2
18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-nice.2715 uuid:
78e2f556-9829-42fe-963d-e19dfc43c0e9 Mar 3 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid:
e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020

Bruce O'Neel-2

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by timrowledge

HI,

You're right. I have the following with top to bottom:

Pi 3, Rasp PI OS based on Debian Stretch 9.0, Squeak 6.0alpha 20509, VM Cog[spur] built from 20210109.

Pi 400, Rasp PI OS based on Debian Buster 10.0, Squeak 6.0alpha 20509, VM Cog[spur] built from 202109

x86-64 Linux, Mint 20.1 (ubuntu 20.4), Squeak 6.0alpha 20509, VM Cog[spur] built form 20210109.

Windows x86-64, Win 10, Squeak 6.0alpha 20509, VMCog[spur] built from 20200302. I think that's the release VM for windows.

and finally a broken one.

Armv8, Debian 18.4 (I think), Squeak6.0alpha 20509, but VM built 20210324. I'll move back to the older VM and try again.

cheers

bruce

07 May 2021 01:33 tim Rowledge <[hidden email]> wrote:

I was just about to say something about Chris'question and tried

2 raisedTo: 63

in a Workspace. I was a little surprised to see '0' returned.

On my Mac 64 I get the right answer. On the Pi I get the right(ish) answer if I substitute 2.0. To make things weirder if I debug, the end value of 'result' in Number>>#raisedToInteger: is correct. The value of 'stack top' in its sender #raisedTo: is the same correct value.

Gronk? It's clearly not a problem with printing the value since I see the correct value. If I try
(2 raisedTo: 63) / 64.0
to check what number is actually there... I get 0. Implying there is really 0. Debug it and.. yup 0. What? It looks like somewhere the LPI instance is getting mishandled but where?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CSD: Charge Surreptitiously to DOE

Bruce O'Neel-2

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

Same results on the ArmV8 with the VM from 20210109.

2 raisedTo: 61 works, 2 raisedTo: 62 and above don't work.

07 May 2021 12:21 "Bruce O'Neel" <[hidden email]> wrote:

HI,

You're right. I have the following with top to bottom:

Pi 3, Rasp PI OS based on Debian Stretch 9.0, Squeak 6.0alpha 20509, VM Cog[spur] built from 20210109.
Pi 400, Rasp PI OS based on Debian Buster 10.0, Squeak 6.0alpha 20509, VM Cog[spur] built from 202109
x86-64 Linux, Mint 20.1 (ubuntu 20.4), Squeak 6.0alpha 20509, VM Cog[spur] built form 20210109.
Windows x86-64, Win 10, Squeak 6.0alpha 20509, VMCog[spur] built from 20200302. I think that's the release VM for windows.

and finally a broken one.
Armv8, Debian 18.4 (I think), Squeak6.0alpha 20509, but VM built 20210324. I'll move back to the older VM and try again.

cheers

bruce

<image.png>

07 May 2021 01:33 tim Rowledge <[hidden email]> wrote:
I was just about to say something about Chris'question and tried

2 raisedTo: 63

in a Workspace. I was a little surprised to see '0' returned.

On my Mac 64 I get the right answer. On the Pi I get the right(ish) answer if I substitute 2.0. To make things weirder if I debug, the end value of 'result' in Number>>#raisedToInteger: is correct. The value of 'stack top' in its sender #raisedTo: is the same correct value.

Gronk? It's clearly not a problem with printing the value since I see the correct value. If I try
(2 raisedTo: 63) / 64.0
to check what number is actually there... I get 0. Implying there is really 0. Debug it and.. yup 0. What? It looks like somewhere the LPI instance is getting mishandled but where?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: CSD: Charge Surreptitiously to DOE

<>

David T. Lewis

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by timrowledge

On Thu, May 06, 2021 at 04:33:55PM -0700, tim Rowledge wrote:

> I was just about to say something about Chris'question and tried
>
> 2 raisedTo: 63
>
> in a Workspace. I was a little surprised to see '0' returned.
>
> On my Mac 64 I get the right answer. On the Pi I get the right(ish) answer if I substitute 2.0. To make things weirder if I debug, the end value of 'result' in Number>>#raisedToInteger: is correct. The value of 'stack top' in its sender #raisedTo: is the same correct value.
>
> Gronk? It's clearly not a problem with printing the value since I see the correct value. If I try
> (2 raisedTo: 63) / 64.0
> to check what number is actually there... I get 0. Implying there is really 0. Debug it and.. yup 0. What? It looks like somewhere the LPI instance is getting mishandled but where?
>

Whatever the issue turns out to be, we need to turn it into a unit
test in trunk. It's a serious failure that is very easy to overlook.

It only takes 8 passes through the look in Number>>raisedToInteger:
to get to the solution, so you should be able to use a debugger to
see where things are going wrong. Or print to Transcript and see
where it fails.

For example if I use this:

Number>>raisedToInteger: anInteger
"The 0 raisedToInteger: 0 is an special case. In some contexts must be 1 and in others must
be handled as an indeterminate form.
I take the first context because that's the way that was previously handled.
Maybe further discussion is required on this topic."

| bitProbe result |
anInteger negative ifTrue: [^(self raisedToInteger: anInteger negated) reciprocal].
bitProbe := 1 bitShift: anInteger highBit - 1.
result := self class one.
[
Transcript showln: 'TOP LOOP ', result asString, ' BITPROBE ', bitProbe asString.
(anInteger bitAnd: bitProbe) > 0 ifTrue: [ result := result * self ].
(bitProbe := bitProbe bitShift: -1) > 0 ]
whileTrue: [ result := result squared .
Transcript showln: 'INNER LOOP ', result asString].
^result

Then the (good) output on the Transcript is:

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
TOP LOOP 1 BITPROBE 8
INNER LOOP 100
TOP LOOP 100 BITPROBE 4
INNER LOOP 10000
TOP LOOP 10000 BITPROBE 2
INNER LOOP 100000000
TOP LOOP 100000000 BITPROBE 1
INNER LOOP 4611686018427387904
TOP LOOP 1 BITPROBE 8
INNER LOOP 100
TOP LOOP 100 BITPROBE 4
INNER LOOP 10000
TOP LOOP 10000 BITPROBE 2
INNER LOOP 100000000
TOP LOOP 100000000 BITPROBE 1
TOP LOOP 4611686018427387904 BITPROBE 1

If you run the same thing on the Pi VM, I expect you will see something quite different.

Dave

timrowledge

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A one-bit brain with a parity error.

David T. Lewis

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

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

Bruce O'Neel-2

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

Hi,

Tim seems to be using a 64 bit VM on the Pi 4. I do not see it on 32 bit VMs on a Pi 3 nor on a Pi 400, so the same hardware. I do see it on a Arm64 system though.

So it seems, for once, not to be a 32 bit system problem and does seem to be just Arm64.

cheers

bruce

09 May 2021 16:31 "David T. Lewis" <[hidden email]> wrote:

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

David T. Lewis

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

youtube.com/watch?v=OjYoNL4g5Vg

Dave

On Sun, May 09, 2021 at 04:56:44PM +0200, Bruce O'Neel wrote:

>
>
> Hi,
>
> Tim seems to be using a 64 bit VM on the Pi 4. I do not see it on 32 bit VMs on a Pi 3 nor on a Pi 400, so the same hardware. ??I do see it on a Arm64 system though.
>
> So it seems, for once, not to be a 32 bit system problem and does seem to be just Arm64.
>
> cheers
>
> bruce
>
>
>
> > 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
>
>

timrowledge

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by David T. Lewis

> On 2021-05-09, at 7:31 AM, David T. Lewis <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

codefrau

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

On Sun, May 9, 2021 at 10:57 tim Rowledge <[hidden email]> wrote:

So we're rather pointed to some peculiarity of the 16r80000000 bit-pattern? My brian hurts.

That is a very peculiar bit pattern indeed, in that it is exactly where signed arithmetic wraps around. So signed/unsigned or < vs <= or a combination thereof perhaps?

If you want some *real* fun step through it under gdb 😬

–Vanessa–

Bruce O'Neel-2

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by timrowledge

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

09 May 2021 19:56 tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

Bruce O'Neel-2

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

Hi,

A bit more testing and I think I can guess why Tim sees it work or not work some time.

Note that below that result is correct for 2 raisedTo: 64.

Somewhere walking back up the stack it loses the value.

So ok:

One level up, still ok:

Still ok

But then somewhere between here, and actually printing the value we lose it.

I don't get why.

Thanks

bruce

10 May 2021 12:54 "Bruce O'Neel" <[hidden email]> 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.png>

09 May 2021 19:56 tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

codefrau

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by Bruce O'Neel-2

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 <[hidden email]> 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

09 May 2021 19:56 tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

timrowledge

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by codefrau

> On 2021-05-09, at 8:07 PM, Vanessa Freudenberg <[hidden email]> wrote:
>
> On Sun, May 9, 2021 at 10:57 tim Rowledge <[hidden email]> wrote:
>
> So we're rather pointed to some peculiarity of the 16r80000000 bit-pattern? My brian hurts.
>
> That is a very peculiar bit pattern indeed, in that it is exactly where signed arithmetic wraps around. So signed/unsigned or < vs <= or a combination thereof perhaps?

Yeah, very plausible

>
> If you want some *real* fun step through it under gdb 😬

Doing anything in gdb stopped being 'fun' a long time ago. But I suppose I may have to just hold my nose and try...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Dukedom: aristocratic birth control

timrowledge

Re: 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)

In reply to this post by Bruce O'Neel-2

> On 2021-05-10, at 7:06 AM, Bruce O'Neel <[hidden email]> wrote:
> A bit more testing and I think I can guess why Tim sees it work or not work some time.
>
> Note that below that result is correct for 2 raisedTo: 64.

Yeah, that weirded me a bit when I first debugged this.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Ignorant, and proud of it.