Thanks for testing it. I had actually tested it on my Pi3 B both in
32-bit and 64-bit modes. The issue was the fact that Test174 failed and
the question was why and whether there was a serious bug. Having traced
it to the rounding in the conversion from Real.real to Real32.real I
have to say that I don't see that it is worth spending any more time on
this.
Regards,
David
On 30/03/2019 00:04, mmoel wrote:
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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
