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


From: Simon Pickering
Subject: RE: lo_ieee_init: unrecognized floating point format! on ARM platform
Date: Fri, 23 Sep 2005 12:31:44 -0500

 
> 
> | I suppose I should be able to compare my output to the test 
> cases in 
> | mach-info.cc, though I'll have to do some more reading to 
> work out how 
> | to convert the normal numbers returned by d1mach into the tuples in 
> | the INIT_FLT_PAR structures.
> 
> You can do it by storing the double values in the d field of
> 
>   union equiv
>   {
>     double d;
>     int i[2];
>   };
> 
> and looking at the elements of the i field.

Okay, I'll do that, thanks.

> | I note that even if it's nothing to do with --float-store there are 
> | other issues to do with double rounding, etc. which may 
> still have an 
> | effect - so I'll have to have a look at how machar works 
> and see if I 
> | can work out where things are going wrong.
> 
> OK.
> 
> Can you try a different gcc version for this file?

Yes, that's doable (assuming there aren't name mangling issues between the
versions I'll have to check, otherwise I'll just re-compile the whole lot),
might take a little while to rebuild the cross-toolchain though - any
suggestions on a specific version?

> | One last question - flt_fmt_cray is assumed without performing any 
> | tests, from the CRAY #define; this leads me (slightly OT) 
> to ask why 
> | it can't be tested for (I should probably look in the mailing list 
> | archive for this though),
> 
> I don't think you would find anything about it.  This hack 
> was done for an incomplete port to a Cray SV-1 that I was 
> working on.  I don't remember all the details, but I think 
> one problem was that sizeof
> (int) == sizeof (double).  Maybe machar was failing to do the 
> right thing too.  I can't remember.  It doesn't really matter 
> though, as Octave will likely not work well on that system 
> anyway.  I don't see this as a big problem though, since 
> there are not so many of them around.

Thanks for the explanation - I was just interested as I saw it in there.

> |  and more importantly to ask just how much of the code is in fact 
> | dependent on the flt_fmt type? My reason for asking this, 
> is that even 
> | with the warning, the test calculations I've performed using the 
> | Zaurus appear to produce the correct answers; what kind of 
> calculation 
> | would I need to perform to see a problem in the results?
> 
> It matters for deciding what to do for load/save in binary 
> formats, at least when you are swapping byte order, fread/fwrite, etc.

Okay.

> If you aren't concerned that your compiler might be 
> miscompiling machar, then just hack the flt_fmt code to force 
> the format to be ieee big endian and cross your fingers.  :-)

I'll certainly try to track down the problem rather than hacking it away. 

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.

Thanks for your help; I'll post to the list once I've had a look to let you
know what I find,

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



reply via email to

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