[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: lo_ieee_init: unrecognized floating point format! on ARM platform(re
|
From: |
Simon Pickering |
|
Subject: |
RE: lo_ieee_init: unrecognized floating point format! on ARM platform(revisited) |
|
Date: |
Fri, 2 Feb 2007 12:59:00 -0000 |
> | The values returned by Octave (either using format bit, or the patched
> | version of machar) on the Nokia 770 are as follows:
> |
> | eps 2.2204460492503131e-16 0 3CB00000
> | epsneg 1.1102230246251565e-16 0 3CA00000
> | xmin 4.9406564584124654e-324 1 0
> | xmax inf 0 7FF00000
> |
> | So xmax and xmin differ.
> |
> | I have a couple of questions:
> |
> | Why is this endianness check carried out at run-time rather than at
> | compile time (in configure for example, as R does)?
>
> Because a configure-time check will fail when cross compiling.
Yes, fair enough, and I suppose the check is only run once at start-up so it
doesn't add much overhead.
> | Is the test designed to test the endianness, or the correctness of the
> | fp implementation. I ask because I think there are simpler ways to
> | check endianness if that's all that's needed.
>
> We need to know whether it is IEEE big/little endian. If
> your system really does implement one of these, then it is
> surprising that xmax and xmin are different. In particular,
> xmax looks wrong because it should not be Inf. What does
> paranoia compute for these values?
The paranoia output is rather long, and I'm not sure whether the list
accepts attachments so here's a link to the output in a text file:
http://people.bath.ac.uk/enpsgp/benchmarks/770-paranoia-output.txt
>From this, it would appear that the system is IEEE compliant.
> Maybe the bug is in the machar code used by Octave to generate them.
I also have a Nokia N800 which has hardware floating point (a hw
implementation of the same VFP code), but can also run soft-float code. When
compiled for hard-float, Octave doesn't produce a warning (as the outputs
match those expected - see below).
I'm not sure how much use this is, but these are the results of the patched
version of machar.c you provided on the list a few years ago (and then
modified again to produce extra intermediate output to track down where the
difference arises. The code itself is here:
http://people.bath.ac.uk/enpsgp/benchmarks/machar.c):
================================================================
# Hard-float VFP
================================================================
Nokia-N800-51:/home/user/benchmark# ./a.vfp.out
determine ibeta,beta ala malcolm
tmp <> zero when a= 9.0071992547409920e+15 0 43400000
tmp <> zero when b= 2.0000000000000000e+00 0 40000000
ibeta= 2.0000000000000000e+00 0 40000000
beta= 2.0000000000000000e+00 0 40000000
determine irnd, it
tmp <> zero when b= 9.0071992547409920e+15 0 43400000
tmp <> zero when tmp= -1.0000000000000000e+00 0 BFF00000
irnd= 2.0000000000000000e+00 0 40000000
determine negep, epsneg
tmp <> zero when negep= 5.3000000000000000e+01 0 404A8000
tmp <> zero when a (epsneg)= 1.1102230246251565e-16 0 3CA00000
determine machep, eps
tmp-one <> zero when a (eps)= 2.2204460492503131e-16 0 3CB00000
determine ngrd
ngrd= 0.0000000000000000e+00 0 0
determine iexp, minexp, xmin
loop break with tmp1= 2.7813423231340017e-309 0 20000
loop break with tmp= 5.5626846462680035e-309 0 40000
loop break with z= 5.5626846462680035e-309 0 40000
determine k such that (1/beta)**k does not underflow
loop to determine minexp, xmin.
loop break ((tmp1 == y) && (tmp != y))
loop break with nxres= 3.0000000000000000e+00 0 40080000
loop break with xmin= 2.2250738585072014e-308 0 100000
loop break with minexp= -1.0220000000000000e+03 0 C08FF000
determine maxexp, xmax
loop break with mx= 2.0480000000000000e+03 0 40A00000
loop break with iexp= 4.0000000000000000e+00 0 40100000
loop break with maxexp= 1.0260000000000000e+03 0 40900800
Adjust *irnd to reflect partial underflow.
Before irnd= 2.0000000000000000e+00 0 40000000
After irnd= 5.0000000000000000e+00 0 40140000
Adjust for IEEE style machines.
Before maxexp= 1.0260000000000000e+03 0 40900800
Making adjustment for IEEE style machines: (*maxexp) = (*maxexp)-2
After maxexp= 1.0240000000000000e+03 0 40900000
adjust for machines with implicit leading bit
(i > 0): xmax= 5.6177910464447366e+306 FFFFFFFF 7F9FFFFF
xmax= 2.2471164185778946e+307 FFFFFFFF 7FBFFFFF
Double precision MACHAR constants
ibeta = 2
it = 53
irnd = 5
ngrd = 0
machep = -52
negep = -53
iexp = 4
minexp = -1022
maxexp = 1024
eps 2.2204460492503131e-16 0 3CB00000
epsneg 1.1102230246251565e-16 0 3CA00000
xmin 2.2250738585072014e-308 0 100000
xmax 2.2471164185778946e+307 FFFFFFFF 7FBFFFFF
================================================================
# Soft-float VFP
================================================================
Nokia-N800-51:/home/user/benchmark# ./a.soft-vfp.out
determine ibeta,beta ala malcolm
tmp <> zero when a= 9.0071992547409920e+15 0 43400000
tmp <> zero when b= 2.0000000000000000e+00 0 40000000
ibeta= 2.0000000000000000e+00 0 40000000
beta= 2.0000000000000000e+00 0 40000000
determine irnd, it
tmp <> zero when b= 9.0071992547409920e+15 0 43400000
tmp <> zero when tmp= -1.0000000000000000e+00 0 BFF00000
irnd= 2.0000000000000000e+00 0 40000000
determine negep, epsneg
tmp <> zero when negep= 5.3000000000000000e+01 0 404A8000
tmp <> zero when a (epsneg)= 1.1102230246251565e-16 0 3CA00000
determine machep, eps
tmp-one <> zero when a (eps)= 2.2204460492503131e-16 0 3CB00000
determine ngrd
ngrd= 0.0000000000000000e+00 0 0
determine iexp, minexp, xmin
loop break with tmp1= 2.7813423231340017e-309 0 20000
loop break with tmp= 5.5626846462680035e-309 0 40000
loop break with z= 5.5626846462680035e-309 0 40000
determine k such that (1/beta)**k does not underflow
loop to determine minexp, xmin.
loop break ((tmp1 == zero) || (ABS(y) >= (*xmin)))
loop break with minexp= -1.0740000000000000e+03 0 C090C800
determine maxexp, xmax
loop break with mx= 2.0480000000000000e+03 0 40A00000
loop break with iexp= 4.0000000000000000e+00 0 40100000
loop break with maxexp= 9.7400000000000000e+02 0 408E7000
Adjust *irnd to reflect partial underflow.
Before irnd= 2.0000000000000000e+00 0 40000000
After irnd= 2.0000000000000000e+00 0 40000000
Adjust for IEEE style machines.
Before maxexp= 9.7400000000000000e+02 0 408E7000
Making adjustment for IEEE style machines: (*maxexp) = (*maxexp)-2
After maxexp= 9.7200000000000000e+02 0 408E6000
adjust for machines with implicit leading bit
Double precision MACHAR constants
ibeta = 2
it = 53
irnd = 2
ngrd = 0
machep = -52
negep = -53
iexp = 4
minexp = -1074
maxexp = 972
eps 2.2204460492503131e-16 0 3CB00000
epsneg 1.1102230246251565e-16 0 3CA00000
xmin 4.9406564584124654e-324 1 0
xmax inf 0 7FF00000
================================================================
To summarise, I'm quite happy to run other tests to establish the IEEE 754
compliance of the soft-float VFP code, and would equally be happy to patch
Octave to allow soft-float ARM systems to be recognised correctly (though
whether this is achieved by adding extra tests, modifying the current test,
or re-designing the test I'm not sure).
If patching, I'd also be interested to move the endianness test away from
analysing a floating point number as this may produce unexpected results for
soft-float FPA systems (which always store their floating point numbers in
bigendian form). This was where I got to last time round, but was then
waiting to move to soft-float VFP, hoping it would sort out both the
endianness and the differing values. It has sorted out the endianness but
not the values.
Is the endianness needed to manipulate floating point numbers themselves
directly (e.g. the bit manipulations of NaNs that R performs to make a new
type of number - the NA), or is it a generic test used for things such as
stream reading? If both then it would need more changes and might not be
worth the bother (as I don't use FPA anymore).
Sorry for the long email,
Thanks,
Simon