Spivoxity / obc-3

Oxford Oberon-2 compiler
38 stars 7 forks source link

Weak and wobbly floating point results with JIT (3.1) #21

Closed Spivoxity closed 5 years ago

Spivoxity commented 5 years ago

Christian Kleinert reported:

Compiled the current source on macOS: Oxford Oberon-2 compiler driver version 3.1alpha [build unknown] Oxford Oberon-2 compiler version 3.1alpha [build unknown] Oxford Oberon-2 linker version 3.1alpha [build unknown] Oxford Oberon-2 runtime system version 3.1alpha [build unknown] (JIT)

When running the attached whetstones test, with JIT enabled, it takes approx. 40-50% longer and shows wrong results with lots of NaN. With JIT disabled, results appear as expected.

Whetstones.m.txt

Spivoxity commented 5 years ago

Thank you: that is a useful test case, and I will incorporate it into the build.

But please note that the default branch is used for development, and it is highly likely that checkins will build only on Linux/amd64 and be broken on other platforms. Bug reports of the form "Won't build on platform X" don't help very much. Bug reports with a test case that fails on platform X may be a bit more useful, but only if the revision you build passes the usual regression tests on the platform ("make test"), and only if you identify the revision by its hash code, which you can find in the column headed Commit on the page https://bitbucket.org/Spivey/obc-3/commits/all.

If you want a version that's more likely to build and run, try the head of the release branch rel-3.0, or better still (though it amounts to the same thing at present) the latest tagged release on that branch. I will compile rel-3.0.7 for various platforms when I have the chance, and put the results on the Downloads page. But MacOS requires me to find and power up a real Mac, so happens only when I and the Mac are in the same place. Would anyone like to buy me a Mac mini to use as a build server?

Some relevant news about rel-3.1: first, it has a native JIT for amd64, instead of relying on the i386 JIT. Second, it has a revised implementation of floating point comparisons that treats NaNs properly, so that e.g. Nan = Nan is false. The first piece of news means that there may still be problems with compliance with the ABI on different platforms that only time will sort out. The second news means that all floating point code will be suspect until I've had chance to verify the many translation tables

Oberon --> Keiko --> Thunder --> Native assembler --> Binary opcodes

that intervene between the code you write and the instructions the processor obeys. Those tables can only be checked by exhaustive testing, and I wrote some of them on a bus!

I'm marking the report invalid, but I'm still grateful for the code.

-- Mike

Spivoxity commented 5 years ago

Christian: thanks a lot for the hints, switched to the 3.0.7 branch and compiled from there. will use this version instead of the 3.1alpha.

have no recent mac mini to give away (only a retro 2006 model and a 2008 unibody macbook, not supported by recent OS laying around), but if i figure out how to get the gtk debugger to build (currently using ./configure --disable-debugger due to some build errors with a brew installation of gtk and support libs), maybe I could help generating the macOS .pkg.

kind regards, Christian.

Spivoxity commented 5 years ago

Substantial quantities of sacrificed chicken blood are used in building with GTK -- each time I set it up, I resolve to write up the procedure but never quite finish it. Apart from the chicken blood, the main ingredient is a package tool for GTK called JHBuild:

https://wiki.gnome.org/Projects/GTK%2B/OSX/Building

But there are bugs with the macOS-specific code of GTK, missing pgkconfig files, etc. All the fixes that are needed are contained in the macport subdirectory.