Smalltalk › Squeak › Squeak VM

Optimisation and ArmV8 64 bit systems

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Bruce O'Neel-2

Optimisation and ArmV8 64 bit systems

Hi,

On my tiny Arm V8 system (Nvidia Jetson Nano, Arm A57, https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-nano/) running Nvidia's distribution of Ubuntu 18.04 the optimised build for a VM that doesn't do floating point. For example 1.0 / 3.0 is 0.0. Gcc version 7.4.0.

The debug build, and the assert build both work fine.

If I reduce the optimisation from -O2 to -O1 it's ok.

I'm building the VM in opensmalltalk-vm/build.linux64ARMv8/squeak.stack.spur.

This is more to stop someone from as much head scratching for them as it is for me...

Thanks.

bruce

Levente Uzonyi

Re: Optimisation and ArmV8 64 bit systems

Hi Bruce,

You're probably seeing the issue described here:
http://forum.world.st/Primitive-40-asFloat-fails-for-me-td5095689.html

You may want to check if this part applies to your build as well:

> Actually the returned float object is -100.0 (-100 asFloat < 0.0 returns
> true), but the code used for printing doesn't work properly, because
> #basicAt: returns 0 (when the argument is 1 or 2), and the method used to
> print the number uses #signBit to print the negative sign, and #signBit
> relies on #basicAt: returning a non-zero value when the number is
> negative.

> So, we're back to the original issue I found: #basicAt: (primitive 38)
> doesn't work with newer gcc versions

Levente

Bruce O'Neel-2

Re: Optimisation and ArmV8 64 bit systems

Hi,

Yep, that seems to be the problem.

So Gcc 7 (and I guess gcc 8) with -O2 and our code seems to optimise into a problem.

Thanks.

bruce

21 October 2019 01:46 Levente Uzonyi <[hidden email]> wrote:

Hi Bruce,

You're probably seeing the issue described here:
http://forum.world.st/Primitive-40-asFloat-fails-for-me-td5095689.html

You may want to check if this part applies to your build as well:

> Actually the returned float object is -100.0 (-100 asFloat < 0.0 returns
> true), but the code used for printing doesn't work properly, because
> #basicAt: returns 0 (when the argument is 1 or 2), and the method used to
> print the number uses #signBit to print the negative sign, and #signBit
> relies on #basicAt: returning a non-zero value when the number is
> negative.

> So, we're back to the original issue I found: #basicAt: (primitive 38)
> doesn't work with newer gcc versions

Levente

Mariano Martinez Peck

Re: Optimisation and ArmV8 64 bit systems

Hi Bruce,

It seems Levente did help you with your issue. I just wanted to add a link to a blog post I wrote with my experiments with VASmalltalk, Jetson Nano and TensorFlow.

Even if its another Smalltalk dialect, you may find interesting bits on it: https://dev.to/martinezpeck/getting-started-with-nvidia-jetson-nano-tensorflow-and-smalltalk-23mk

Best regards,

On Mon, Oct 21, 2019 at 3:18 PM Bruce O'Neel <[hidden email]> wrote:

Hi,

Yep, that seems to be the problem.

So Gcc 7 (and I guess gcc 8) with -O2 and our code seems to optimise into a problem.

Thanks.

bruce

21 October 2019 01:46 Levente Uzonyi <[hidden email]> wrote:
Hi Bruce,

You're probably seeing the issue described here:
http://forum.world.st/Primitive-40-asFloat-fails-for-me-td5095689.html

You may want to check if this part applies to your build as well:

> Actually the returned float object is -100.0 (-100 asFloat < 0.0 returns
> true), but the code used for printing doesn't work properly, because
> #basicAt: returns 0 (when the argument is 1 or 2), and the method used to
> print the number uses #signBit to print the negative sign, and #signBit
> relies on #basicAt: returning a non-zero value when the number is
> negative.

> So, we're back to the original issue I found: #basicAt: (primitive 38)
> doesn't work with newer gcc versions

Levente

Mariano Martinez Peck

Email: [hidden email]

Twitter: @MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/