Smalltalk › Squeak › Squeak VM

FFI Testing - Curiouser and curiouser!

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

KenDickey

FFI Testing - Curiouser and curiouser!

I noted a number of code generation differences between various gcc versions for aarch64, but there is something different going on.

When I copied VM binaries produced on the Chromebook Plus to Raspberry Pi 3 (ArchLinuxArm), the same 2 unit tests fail in Cuis!

So I am now guessing there must be a shared library difference (perhaps libm ?)

Having the same 2 tests fail on x86_64 would preclude a bad CPU chip.

???
-KenD

-KenD

Eliot Miranda-2

Re: FFI Testing - Curiouser and curiouser!

Hi Ken,

On Wed, Feb 13, 2019 at 1:58 PM <[hidden email]> wrote:

I noted a number of code generation differences between various gcc versions for aarch64, but there is something different going on.
When I copied VM binaries produced on the Chromebook Plus to Raspberry Pi 3 (ArchLinuxArm), the same 2 unit tests fail in Cuis!
So I am now guessing there must be a shared library difference (perhaps libm ?)
Having the same 2 tests fail on x86_64 would preclude a bad CPU chip.

What are the failing tests? If they are comparing float values could it simply be a precision error that requires inexact float comparison? (e.g. (a - b) abs < epsilon)

???
-KenD

_,,,^..^,,,_

best, Eliot

KenDickey

Re: FFI Testing - Curiouser and curiouser!

On 2019-02-13 18:57, Eliot Miranda wrote:

> What are the failing tests? If they are comparing float values could
> it simply be a precision error that requires inexact float comparison?
> (e.g. (a - b) abs < epsilon)

Ah! Yes. That nailed it!
Thinking. Gotta try that next time! Radical approach to the solution,
however. ;^)

Thanks for all,
-KenD

FFITests.pck.st (40K) Download Attachment

-KenD

Andres Valloud-8

Re: FFI Testing - Curiouser and curiouser!

Something doesn't look right there. The test in question appears to be
adding all integers from 1 to 9 as floating point numbers, and seems to
be expecting the result is 45 as a floating point number. That
calculation should need no epsilons, it's lossless in floating point
land (under the usual assumptions). What's going on, exactly?

On 2/14/19 09:17, [hidden email] wrote:

>
>
>
> On 2019-02-13 18:57, Eliot Miranda wrote:
>
>> What are the failing tests? If they are comparing float values could
>> it simply be a precision error that requires inexact float comparison?
>> (e.g. (a - b) abs < epsilon)
>
> Ah! Yes. That nailed it!
> Thinking. Gotta try that next time! Radical approach to the solution,
> however. ;^)
>
> Thanks for all,
> -KenD

KenDickey

Re: FFI Testing - Curiouser and curiouser!

On 2019-02-14 16:39, Andres Valloud wrote:
> Something doesn't look right there. The test in question appears to
> be adding all integers from 1 to 9 as floating point numbers, and
> seems to be expecting the result is 45 as a floating point number.
> That calculation should need no epsilons, it's lossless in floating
> point land (under the usual assumptions). What's going on, exactly?
>

I am clueless. Different compiler versions. Different silocon. All
gcc+Linux. All "git cloned" from same
https://github.com/KenDickey/opensmalltalk-vm (cloned from OPenSmalltalk
w minor changes).

Vanilla (epsilon-less) test:
- Failed on Raspberry Pi 3 (Broadcom aarch64) and older x86_64.
- Passed on aarch64 Samsung Chromebook Plus (Rockchip) and LePotato
(AMLogic).
I have stepped through the call to ffiTestDoubles9 with gdb, which
returns float(45.) but get lost in the various alloc,copy,shift,mask
mechanics as things unwind in the interpreter vm.

It is beyond my poor shrinking brain..
-KenD

-KenD

Juan Vuletich-3

Re: FFI Testing - Curiouser and curiouser!

On 2/15/2019 1:55 PM, [hidden email] wrote:

>
> On 2019-02-14 16:39, Andres Valloud wrote:
>> Something doesn't look right there. The test in question appears to
>> be adding all integers from 1 to 9 as floating point numbers, and
>> seems to be expecting the result is 45 as a floating point number.
>> That calculation should need no epsilons, it's lossless in floating
>> point land (under the usual assumptions). What's going on, exactly?
>>
>
> I am clueless. Different compiler versions. Different silocon. All
> gcc+Linux. All "git cloned" from same
> https://github.com/KenDickey/opensmalltalk-vm (cloned from
> OPenSmalltalk w minor changes).
>
> Vanilla (epsilon-less) test:
> - Failed on Raspberry Pi 3 (Broadcom aarch64) and older x86_64.
> - Passed on aarch64 Samsung Chromebook Plus (Rockchip) and LePotato
> (AMLogic).
> I have stepped through the call to ffiTestDoubles9 with gdb, which
> returns float(45.) but get lost in the various alloc,copy,shift,mask
> mechanics as things unwind in the interpreter vm.
>
> It is beyond my poor shrinking brain..
> -KenD

When it fails, what are the 8 bytes you get in gdb? What are the 8 bytes
you get in Cuis (in the Cuis debugger, at the moment of the failure).

--
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

KenDickey

Re: FFI Testing - Curiouser and curiouser!

On 2019-02-17 05:44, Juan Vuletich wrote:

> When it fails, what are the 8 bytes you get in gdb? What are the 8
> bytes you get in Cuis (in the Cuis debugger, at the moment of the
> failure).

Hi Juan, happen to be on old amd x86_64 Linux box right now.

If I set a gdb breakpoint at ffiTestDoubles9 and step through it, I end
up in
src/plugins/SqueakFFIPrims/IA32FFIPlugin.c

result2 = floatObjectOf(floatRet1);

At this point
floatRet1 = 0x4046800000000000
after step
result2 = 0x846800000000004

which looks right to me.

Continuing, the result is Smalltalk is SmallInteger 0.0 !

Result seems to get lost somewhere.

I have my RasPi unplugged at the moment.. Have to get back w result
there.

HTH,
-KenD

-KenD