Hi,
please allow me a few words on ARM.
I just tried 'polyml 5.8 git master' on a Raspberry Pi3 B. uname -a is: Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux OS is Raspbian 'Stretch' (Debian). Please find the results below.
It's been quite a while since we ported code from Sun and x86 to ARM. The main problem is, you first have to figure out what you've really got. ARM may run in little or big endian, it may have a certain feature, or not, depending on the implementation. Hence gcc compiler switches may work as expected, not at all, or anything in between.
For example, the above 'armv7l' really is a 64 bit armv8 running in 32 bit mode. However, the Programmers Guide for ARMv8 says it can do the following conversions on floating point values:
FCVT Sd, Hn // half-precision to single-precision FCVT Dd, Hn // half-precision to double-precision FCVT Hd, Sn // single-precision to half-precision FCVT Hd, Dn // double-precision to half-precision
But only if it is implemented. It is allowed to leave floating point out, or implementing it with or without exception trapping.
Back then porting the code was difficult since a lot of maths was involved. It's not without cause the Programmers Guide says you are well advised to do away with each and every compiler warning. Anyway, the solution was to leave the compiler with no choice regarding data types.
Regards Michael
./configure make compiler
realconv.cpp: In function ?char* rv_alloc(int)?: realconv.cpp:3648:58: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] sizeof(Bigint) - sizeof(ULong) - sizeof(int) + j <= i; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
elfexport.cpp: In member function ?virtual void ELFExport::ScanConstant(PolyObject*, byte*, ScanRelocationKind)?: elfexport.cpp:361:18: warning: unused variable ?offset? [-Wunused-variable] POLYUNSIGNED offset = (char*)a - (char*)memTable[aArea].mtOriginalAddr; ^~~~~~
make check-local
Failed Tests: Succeed/Test174.ML
use "Tests/Succeed/Test174.ML";
val check = fn: bool -> unit val p32 = 3.141592741: ?.Math.real val m32 = ~3.141592741: ?.Math.real val p = 3.141592741: real val m = ~3.141592741: real val pp = 3.141592741: real val it = (): unit val pm = 3.141592741: real val it = (): unit val mp = ~3.141592741: real val it = (): unit val mm = ~3.141592741: real val it = (): unit infix 4 == val == = fn: Real32.real * Real32.real -> bool val it = (): unit val it = (): unit val it = (): unit val it = (): unit val it = (): unit Exception- Fail "incorrect" raised Exception- Fail "incorrect" raised
On Thu, 28 Mar 2019, David Matthews wrote:
Hi Jerry, Thanks for looking at this. I've tried building on the ARM using those flags and it seems that converting a double (Real.real) to a float (Real32.real) ignores the rounding setting and always uses the nearest.
Real32.fromLarge IEEEReal.TO_NEAREST mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_ZERO mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_POSINF mp == m32;
val it = true: bool
Real32.fromLarge IEEEReal.TO_NEGINF mp == m32;
val it = true: bool
I don't know what to do about that. The test is useful on other platforms so it would be a shame to remove it.
So the s390x is big-endian? I don't have access to any big-endian hardware but I managed to find an image for a big-endian Mips machine under Qemu and confirm that there was a problem. Actually finding out what the problem is looks like quite a bit of work especially as it takes a long time to run anything.
Regards, David