[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
-------------------------------------------------------------
- FW: lo_ieee_init: unrecognized floating point format! on ARM platform, Simon Pickering, 2005/09/22
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, Simon Pickering, 2005/09/23
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, John W. Eaton, 2005/09/23
- Re: lo_ieee_init: unrecognized floating point format! on ARM platform, Dmitri A. Sergatskov, 2005/09/23
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform,
Simon Pickering <=
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, John W. Eaton, 2005/09/23
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, Simon Pickering, 2005/09/24
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, Simon Pickering, 2005/09/26
- RE: lo_ieee_init: unrecognized floating point format! on ARM platform, John W. Eaton, 2005/09/26