RE: lo_ieee_init: unrecognized floating point format! on ARM platform

[Simon Pickering]

> | One final interesting fact - although the ARM processors 
> can be either
> | little- or bigendian (well there are 4 modes actually), mine is 
> | running in little-endian mode. That said, to make R compile 
> correctly 
> | I had to specify that it was big-endian and as you've said 
> above - the 
> | output looks to be big-endian too. I think I need to do 
> some reading 
> | up on ARM in general and look at how this affects the 
> machar code, etc.
> 
> You might also try applying the following patch to machar.c, 
> then compiling with
> 
>   gcc -DDP -DTEST machar.c
> 
> then run the resulting binary.  Here is what I see (x86):
> 
>   $ ./a.out
>   Double  precision MACHAR constants
>   ibeta  = 2
>   it     = 53
>   irnd   = 5
>   ngrd   = 0
>   machep = -52
>   negep  = -53
>   iexp   = 11
>   minexp = -1022
>   maxexp = 1024
>   eps      2.2204460492503131e-16          0   3CB00000
>   epsneg   1.1102230246251565e-16          0   3CA00000
>   xmin    2.2250738585072014e-308          0     100000
>   xmax    1.7976931348623157e+308   FFFFFFFF   7FEFFFFF
> 
> If you have IEEE floating point, I'd expect the same numbers, 
> but with the hex values swapped if the byte ordering is 
> different from x86.

Thanks for the patch, that made life easier.

Here's the output:

address@hidden:/media/cf# a.out
Double  precision MACHAR constants
ibeta  = 2
it     = 53
irnd   = 2
ngrd   = 0
machep = -52
negep  = -53
iexp   = 11
minexp = -1074
maxexp = 972
eps      2.2204460492503131e-16   3CB00000          0 
epsneg   1.1102230246251565e-16   3CA00000          0 
xmin    4.9406564584124654e-324          0          1 
xmax                        inf   7FF00000          0 


>From my reading of machar.c, this is what I conclude:

The irnd difference is not a bad thing - I get irnd=2 on the PXA which means
proper rounding as opposed to irnd=5 on x86 which implies rounding with a
partial underflow. Not sure whether this would have any effect.

Minexp and maxexp both differ between the two, which leads to the difference
in the xmin & xmax outputs. I'm not too sure why xmax is inf though.

My reading of this is that the fp implementation on the PXA255 is different
in its range and that it therefore simply requires an additional set of
comparison data in mach-info.cc (though I may be jumping the gun here of
course) and it should be recognised as being bigendian (?) - though I'm
still worried that it's supposed to be running in little-endian mode... 

If this is the case, then I wonder if rather than simply adding in another
test, the preference would be to determine whether the platform is big- or
little-endian in a more generic manner (as it was mentioned that this only
affects writing stuff to disk - or other byte-arrays - so the exact numbers
returned are of no interest; though I don't know enough about the internals
of Octave and may be wrong about this).

Thanks,


Simon



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------