help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lo_ieee_init: unrecognized floating point format! on ARM platform (r


From: David Bateman
Subject: Re: lo_ieee_init: unrecognized floating point format! on ARM platform (revisited)
Date: Wed, 10 Jan 2007 16:33:24 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Wow we tried something similar on a motorola A1200 (as a bit of a joke)
using an Intel PXA270 core and had exactly the same issues. I have no
solution to offer but would be interested in any solutions you might
propose...

D.

Simon Pickering wrote:
> 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
>> -------------------------------------------------------------
>>
>>
>>     
>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>
>   


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]