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.

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