16r80000000 < 16r8000000000000000. "==> false "
[Intel reports true]
I think "good grief" is the only polite response here...
On 2021-06-16, at 4:47 PM, Ken Dickey notifications@github.com wrote:
16r80000000 < 16r8000000000000000. "==> false "
[Intel reports true]
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BBL: Branch on Burned out Light
Yes, but that is probably just another manifestation of the 2 raisedTo: 63 or so problem.
This is a nice test though since it shows that it is not at all in the raisedTo: code but rather a very fundemental bug.
On 2021-06-17T01:51:26.000+02:00, tim Rowledge tim@rowledge.org wrote:
I think "good grief" is the only polite response here...
On 2021-06-16, at 4:47 PM, Ken Dickey notifications@github.com wrote: 16r80000000 < 16r8000000000000000. "==> false " [Intel reports true] — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
tim -- tim Rowledge; tim@rowledge.org; www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: BBL: Branch on Burned out Light
That is indeed a great test case that might help narrow it down:
If you "debug into it" you should see that primitive 3 failed for SmallInteger, and it falls back to Integer's version of `<`. If it doesn't, then it's either the JIT incorrectly short-circuiting the comparison, or primitive 3 incorrectly succeeding.
If instead you do see the super send (as is the case on Intel), then it must be primitive _primDigitCompare_ in LargeIntegers plugin.
Very much sounds like a signed/unsigned problem.
On 2021-06-17 11:57, Vanessa Freudenberg wrote:
That is indeed a great test case that might help narrow it down:
If you "debug into it" you should see that primitive 3 failed for SmallInteger, and it falls back to Integer's version of <. If it doesn't, then it's either the JIT incorrectly short-circuiting the comparison, or primitive 3 incorrectly succeeding.
Tried "Debug It" + "Setp Into" in Squeak and Cuis. Both return 'false' without interior detail.
Also same with current ~/OpenSmalltalk/oscogvm/build.linux64ARMv8/squeak.cog.spur/build as well as the "ARMv8 BitBLT speedups provided by RPi/Ben Avison" VM.
vvv==========================vvv Chromebook:Linux:Arm64:~/Squeak5.3 >>> squeak --version 5.0-202103220146 Sat May 22 19:42:47 PDT 2021 gcc 8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2948 uuid: 935d1ee7-0e61-47a5-92e2-953224c7ffcf May 22 2021 StackToRegisterMappingCogit VMMaker.oscog-eem.2946 uuid: 461911e1-d450-4f05-8a40-7b0470487041 May 22 2021 VM: 202103220146 ***@***.***:OpenSmalltalk/Bavison Date: Sun Mar 21 21:46:24 2021 CommitHash: d494240 Plugins: 202103220146 ***@***.***:OpenSmalltalk/Bavison Linux penguin 5.4.99-12983-g8b7876ab9f5e #1 SMP PREEMPT Sun Feb 21 11:49:16 PST 2021 aarch64 GNU/Linux plugin path: /usr/local/bin/../lib/squeak/5.0-202103220146 [default: /usr/local/lib/squeak/5.0-202103220146/] Chromebook:Linux:Arm64:~/Squeak5.3 >>> ... Chromebook:Linux:Arm64:~/OpenSmalltalk/oscogvm/products/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202106162331
./squeak --version
5.0-202106162331 Wed Jun 16 16:39:14 PDT 2021 gcc 8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2967 uuid: 57b9e5f9-0212-436d-acaf-4e501e470621 Jun 16 2021 StackToRegisterMappingCogit VMMaker.oscog-eem.2953 uuid: 9f3d924e-9226-4242-9b6f-3dad93c7a837 Jun 16 2021 VM: 202106162331 ***@***.***:OpenSmalltalk/oscogvm Date: Wed Jun 16 16:31:37 2021 CommitHash: 58e8b33db Plugins: 202106162331 ***@***.***:OpenSmalltalk/oscogvm Linux penguin 5.4.109-26077-g12746d86825a #1 SMP PREEMPT Mon May 17 21:46:50 PDT 2021 aarch64 GNU/Linux plugin path: /home/kendi3he/OpenSmalltalk/oscogvm/products/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202106162331/ [default: /home/kendi3he/OpenSmalltalk/oscogvm/products/sqcogspur64ARMv8linuxht/lib/squeak/5.0-202106162331/]
^^^==========================^^^
Thanks for testing that. My guess then would be that the jitted code for `<` fails to recognize 16r8000000000000000 as being a LargeInteger (which is unlikely), or knowing it's a LargeInt but thinking it can handle the comparison quickly and failing to do so correctly.
Has anyone built the GdbARMv8Plugin on a Raspberry Pi?
On 2021-06-20, at 4:47 AM, Craig Latta notifications@github.com wrote:
Has anyone built the GdbARMv8Plugin on a Raspberry Pi?
Not to the best of my knowledge. I'd imagine it should work but the performance might be too slow to make it practical for anything beyond basic generate-method, disassemble etc.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Alone together
a0d15af closes this
Closed #571.
On Jul 1, 2021, at 10:54 PM, Tobias Pape ***@***.***> wrote:
a0d15af closes this
But it doesn’t close the issue of not being able to build the GdbARMv8Plugin. Tim, where and how does the build fail?
Have you built the plug-in on eg Mac to see how the build directory is organized? Is the support in build.linux64ARMv8/gdbarmv8 (IIRC?) etc?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I built GdbARMv8Plugin on macOS without a hitch, but during use it failed primitively before doing any actual work, during its startup.
Before that I tried to build in Linux on a Raspberry Pi, but there were multi-level header-ordering problems even worse that the one involving Linux features.h and our sq.h. When I got to the point of two Linux headers both saying they should be included before the other, I stopped. The support in build.linux64ARMv8/gdbarm64 did seem to be as expected, including conf.COG and makeeem.
Verified fixed in interpreter VM on Arn64 Chromebook and RasPi4.
Thanks a bunch!!
On Jul 2, 2021, at 10:28 AM, Craig Latta ***@***.***> wrote:
I built GdbARMv8Plugin on macOS without a hitch, but during use it failed primitively before doing any actual work, during its startup.
I found on macOS 11.x I needed to change the entitlements to include <key>com.apple.security.cs.disable-library-validation</key> <true/>
and I just committed this by mistake. Turns out it does no harm on a 10.14.x build. I no longer have a 10.13.x build environment. So I don’t know if this will break older builds.
It also appears that moving to 10.14.x or later kills 32-bit builds. I used to be able to build 32-bit VMs on 10.13.x.
Before that I tried to build in Linux on a Raspberry Pi, but there were multi-level header-ordering problems even worse that the one involving Linux features.h and our sq.h. When I got to the point of two Linux headers both saying they should be included before the other, I stopped. The support in build.linux64ARMv8/gdbarm64 did seem to be as expected, including conf.COG and makeeem.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/571#issuecomment-873151758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5VUGEFVRGK73JODO47ALTVXZKRANCNFSM462PIHAQ.
Hi
On 3. Jul 2021, at 01:32, Eliot Miranda ***@***.***> wrote:
On Jul 2, 2021, at 10:28 AM, Craig Latta ***@***.***> wrote:
I built GdbARMv8Plugin on macOS without a hitch, but during use it failed primitively before doing any actual work, during its startup.
I found on macOS 11.x I needed to change the entitlements to include <key>com.apple.security.cs.disable-library-validation</key>
<true/>
and I just committed this by mistake. Turns out it does no harm on a 10.14.x build. I no longer have a 10.13.x build environment. So I don’t know if this will break older builds.
It also appears that moving to 10.14.x or later kills 32-bit builds.
seems so.
Apple is issuing warning on first start of every 32-bit application that they'd be unsupported on 10.14.
I used to be able to build 32-bit VMs on 10.13.x.
mvm breaks with
MathPlugin.c deps/FloatMathPlugin.d make[1]: *** No rule to make target `../../platforms/Cross/plugins/FloatMathPlugin/fdlibm/e_acos.c', needed by `build/FloatMathPlugin/acos.o'. Stop. make: *** [build/vm/FloatMathPlugin.lib] Error 2
but this looks actually unrelated…
My uneducated guess is that the entitlement makes no difference…
Best regards -Tobias
Before that I tried to build in Linux on a Raspberry Pi, but there were multi-level header-ordering problems even worse that the one involving Linux features.h and our sq.h. When I got to the point of two Linux headers both saying they should be included before the other, I stopped. The support in build.linux64ARMv8/gdbarm64 did seem to be as expected, including conf.COG and makeeem.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/571#issuecomment-873151758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5VUGEFVRGK73JODO47ALTVXZKRANCNFSM462PIHAQ.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Craig Latta -
Eliot Miranda
-
Ken Dickey
-
tim Rowledge -
Tobias Pape
-
Vanessa Freudenberg