lo_ieee_init: unrecognized floating point format! on ARM platform (revisited)

[Simon Pickering]

Hello all,

I'm revisiting this topic as I now have an EABI compiler which has fixed the
endianness issues I was having with FPA softfloat (as it uses VFP
softfloat). This message may or may not automatically link to the previous
thread, but if not, the last post in that thread was from me, though with a
different email address: address@hidden, on the 26th of September 2005.

To briefly re-iterate, I'm running Octave (2.1.73) on an ARM5 (OMAP 1710)
platform - the Nokia 770. The following message is displayed when Octave is
started:

lo_ieee_init: unrecognized floating point format!

This is caused by a mismatch in the fp data comparison carried out in
oct_mach_info::init_float_format (from mach-info.cc). The expected values
are hardcoded, and the values for the particular processor are generated
using machar (indirectly).

The hardcoded values for a little-endian processor are as follows:

INIT_FLT_PAR (fp[1], oct_mach_info::flt_fmt_ieee_little_endian,
         0,    1048576,
        -1, 2146435071,
         0, 1017118720,
         0, 1018167296);

or in hexadecimal:

        0,    100000,         (xmin)
        FFFFFFFF, 7FEFFFFF,   (xmax)
        0,  3CA00000,         (epsneg)
        0,  3CB00000;         (eps)

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)? 

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.

I have just run paranoia (http://www.netlib.org/paranoia/) on the Nokia 770,
and it passes all of the tests. Therefore, assuming this means that the fp
system is correctly implemented (if people would prefer different tests then
please let me know), can I look at patching the endianness tests carried out
in oct_mach_info::init_float_format to allow for architectures with
different fp parameters (the way I should do this is linked to the two
questions above)?

Many thanks,


Simon

P.S. For interest's sake, the original output from the PXA255 Sharp Zaurus
that I was talking about last year is the same (except for endianness) as
that produced by the Nokia 770.


> -----Original Message-----
> From: Simon Pickering [mailto:address@hidden 
> Sent: 26 September 2005 14:45
> To: address@hidden
> Subject: RE: lo_ieee_init: unrecognized floating point 
> format! on ARM platform
> 
>  
> > | 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.
> 
> To follow up on this point; I had a look in 
> include/bits/endian.h of my cross-toolchain which says the following:
> 
> /* FPA floating point units are always big-endian, irrespective of the
>    CPU endianness.  VFP floating point units use the same endianness
>    as the rest of the system.  */
> 
> As I said in an earlier email, I'm using the FPA soft-float 
> implementation which explains why it appears that my ARM 
> processor is big-endian in the floating point tests, while 
> the system is in fact being run in little-endian mode.
> 
> This mixed endianness looks like it will cause problems in 
> general so I'm looking at changing over to the softvfp method 
> (the endianness of whose floating point numbers matches the 
> system's endianness) now, however it may well be that the 
> data returned by machar will still be different from that 
> returned by the little-endian x86 - I'll post to the list 
> once I've got the cross-toolchain up and running and have 
> compiled Octave and have some new results to show.
> 
> 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
> -------------------------------------------------------------
> 
>