Smalltalk › Squeak › Squeak VM

Doubly weird

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

KenDickey

Doubly weird

Oh, I should point out that the CLI prints:

The 9 doubles are 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

when running the FFI unit tests and:

The 9 doubles are 1.000000 1.000000 1.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

When invoked in a Workspace.

-KenD

-KenD

Eliot Miranda-2

Re: Doubly weird

Hi Ken,

On Tue, Feb 26, 2019 at 11:52 AM <[hidden email]> wrote:

Oh, I should point out that the CLI prints:

The 9 doubles are 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

when running the FFI unit tests and:

The 9 doubles are 1.000000 1.000000 1.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

This looks like the marshaller is accessing the wrong initial arguments. It looks like the object accessed for args 1 & 2 is the same as for arg 0, right? The question is why. I have no clue.

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

best, Eliot

Clément Béra

Re: Doubly weird

In reply to this post by KenDickey

Is this 64 bits or 32 bits ?

If 64, what are the classes of all these floats ?

Might be a conversion problem with one of the float class.

On Tue, Feb 26, 2019 at 8:51 PM <[hidden email]> wrote:

Oh, I should point out that the CLI prints:

The 9 doubles are 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

when running the FFI unit tests and:

The 9 doubles are 1.000000 1.000000 1.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

When invoked in a Workspace.

-KenD

Clément Béra
https://clementbera.github.io/

https://clementbera.wordpress.com/

KenDickey

Re: Doubly weird

In reply to this post by Eliot Miranda-2

On 2019-02-26 13:05, Eliot Miranda wrote:

Hi Ken,

On Tue, Feb 26, 2019 at 11:52 AM <[hidden email]> wrote:

Oh, I should point out that the CLI prints:

The 9 doubles are 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

when running the FFI unit tests and:

The 9 doubles are 1.000000 1.000000 1.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

This looks like the marshaller is accessing the wrong initial arguments. It looks like the object accessed for args 1 & 2 is the same as for arg 0, right? The question is why. I have no clue.

Is there a compiler/runtime/parser change?

Calling

========================

FFIPluginTests>>testGenericDoubleCall2
"Test using generic FFI spec"
| result |
result := FFITestLibrary ffiTestDoubles9: 1.0 d: 2.0 d: 3.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0.
self assert: result = 45.0

=========================

works fine, but in a workspace,

FFITestLibrary ffiTestDoubles9: 1.0 d: 2.0 d: 3.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0. --> 42.0

=========================

Typed space in FFIPluginTests>>testGenericDoubleCall2, accept (s), and source text now shows:

============

FFIPluginTests>>testGenericDoubleCall2
"Test using generic FFI spec"
| result |
result := FFITestLibrary ffiTestDoubles9: 1.0 d: 1.0 d: 1.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0.
self assert: result = 1.0

===============

!?!?!WTF!?!?!

I will download a fresh image and try anew..

-KenD

KenDickey

Re: Doubly weird

In reply to this post by Eliot Miranda-2

OK. Previous image was from Squeak5.2-12225-64bit.zip

Downloaded and unpacked Squeak5.2-18229-64bit-All-in-One.zip

The new image

Now fails the 2 test cases #testGenericDoiubleCall2 and #testGeericMizedDoublesAndInt

FFITestLibrary ffiTestDoubles9: ... -> 42.0 (inspect + 'self hex' also prints zero)

The CLI output also indicates wrong values passed to FFI C code test fun.

Adding a space and accept no longer rewrites the source code, but select button #prettyPrint and the code is again borked!

Could be a parse/tool problem.

Again, this is Monticello repository http://source.squeak.org/FFI

FFI-Pools (TorstenBergmann.4)

FFI-Kernel (eem.56)

FFI-Tests (cbc.9)

I am not a (regular) Squeak user, so am probably not the best person to investigate this..

-KenD

Eliot Miranda-2

Re: Doubly weird

In reply to this post by KenDickey

On Tue, Feb 26, 2019 at 2:06 PM <[hidden email]> wrote:

On 2019-02-26 13:05, Eliot Miranda wrote:

Hi Ken,

On Tue, Feb 26, 2019 at 11:52 AM <[hidden email]> wrote:

Oh, I should point out that the CLI prints:

The 9 doubles are 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

when running the FFI unit tests and:

The 9 doubles are 1.000000 1.000000 1.000000 4.000000 5.000000 6.000000
7.000000 8.000000 9.000000

This looks like the marshaller is accessing the wrong initial arguments. It looks like the object accessed for args 1 & 2 is the same as for arg 0, right? The question is why. I have no clue.

Is there a compiler/runtime/parser change?

No. In the Workspace there is invocation via withArgs:executeMethod:, primitive 188. But I find it hard to believe this is the issue. This code is correct and I don't see there can be any issue with it and have as much of tech system work as you do. In all cases there is only one source to bytecode compiler doing the compiler, best doits, method compilation, image segment load evaluation, etc, etc.

Calling

========================

FFIPluginTests>>testGenericDoubleCall2
"Test using generic FFI spec"
| result |
result := FFITestLibrary ffiTestDoubles9: 1.0 d: 2.0 d: 3.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0.
self assert: result = 45.0

=========================

works fine, but in a workspace,

FFITestLibrary ffiTestDoubles9: 1.0 d: 2.0 d: 3.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0. --> 42.0

=========================

Typed space in FFIPluginTests>>testGenericDoubleCall2, accept (s), and source text now shows:

============

FFIPluginTests>>testGenericDoubleCall2
"Test using generic FFI spec"
| result |
result := FFITestLibrary ffiTestDoubles9: 1.0 d: 1.0 d: 1.0 d: 4.0 d: 5.0 d: 6.0 d: 7.0 d: 8.0 d: 9.0.
self assert: result = 1.0

===============

!?!?!WTF!?!?!

I don't understand. How can typing a space produce a totally different version of the method? Have you checked the bytecode in the

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

best, Eliot

KenDickey

Re: Doubly weird

Tried -O1.

Again, Cuis images run fine but Squeak in this case fails in some primitive drawing routing and dumps me into the emergency evaluator.

In the -O2 case, Cuis calls #ffiTestDoubles9:d:d:d:d:d:d:d:d: -> 45.0, where Squeak -> 42.0.

Unlike Squeak, prettyPrinting the method in Cuis does _not_ rewrite the numbers in the code.

This is the same VM, folks, which suggests something is up with recent Squeak images.

-KenD

Levente Uzonyi

Re: Doubly weird

On Tue, 26 Feb 2019, [hidden email] wrote:

> Tried -O1.

Please try with -O0. That's the only optimization mode reportedly free of
this bug.

> This is the same VM, folks, which suggests something is up with recent Squeak images.

Or perhaps Squeak and Cuis use different methods to print floats and one
of them (Cuis) avoids the use of primitive 38 (#basicAt: in Squeak).

Levente

KenDickey

Re: Doubly weird

In reply to this post by Eliot Miranda-2

Did a build of sqstkspur64linuxht from current git sources on AMD/x86_64
Linux and happy to see that everything worked just fine.

Now building -O0 on aarch64..

Baby steps,
-KenD

-KenD

KenDickey

Re: Doubly weird

In reply to this post by Eliot Miranda-2

OK. Rebuilt with -O0 and Squeak now behaves as expected.

GCC optimization seems to be problem.

Whew! Now if we just knew why...

Thanks to all!

-KenD

PS: Eliot, can you change the
build.linux64ARMv8/squeak.stack.spur/build* 'mvm' files for -O0 ?
Thanks a bunch!

-KenD

Eliot Miranda-2

Re: Doubly weird

Hi Ken,

On Tue, Feb 26, 2019 at 4:52 PM <[hidden email]> wrote:

OK. Rebuilt with -O0 and Squeak now behaves as expected.

GCC optimization seems to be problem.

Whew! Now if we just knew why...

Thanks to all!

-KenD

PS: Eliot, can you change the
build.linux64ARMv8/squeak.stack.spur/build* 'mvm' files for -O0 ?
Thanks a bunch!

You should find that there are all of these:

build.linux64ARMv8/squeak.stack.spur/{build, build.assert,build.debug}

i.e. they're already there.

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

best, Eliot