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
Hi Ken,
On Tue, Feb 26, 2019 at 11:52 AM ken.dickey@whidbey.com 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
On 2019-02-26 13:05, Eliot Miranda wrote:
Hi Ken,
On Tue, Feb 26, 2019 at 11:52 AM ken.dickey@whidbey.com 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
On Tue, Feb 26, 2019 at 2:06 PM ken.dickey@whidbey.com wrote:
On 2019-02-26 13:05, Eliot Miranda wrote:
Hi Ken,
On Tue, Feb 26, 2019 at 11:52 AM ken.dickey@whidbey.com 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
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
On Tue, 26 Feb 2019, ken.dickey@whidbey.com 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
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
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!
Hi Ken,
On Tue, Feb 26, 2019 at 4:52 PM ken.dickey@whidbey.com 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
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
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 ken.dickey@whidbey.com 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
vm-dev@lists.squeakfoundation.org
-
Clément Béra -
Eliot Miranda -
ken.dickey＠whidbey.com -
Levente Uzonyi