[erlang-questions] OTP float error on ARM

[Mikael Pettersson]

Bjorn Gustavsson writes:
 > On Thu, Oct 16, 2008 at 8:51 AM, Bob Ippolito <bob@REDACTED> wrote:
 > 
 > > On Wed, Oct 15, 2008 at 11:28 PM, Bjorn Gustavsson
 > > <bgustavsson@REDACTED> wrote:
 > > >  Thu, Oct 16, 2008 at 7:40 AM, Bob Ippolito <bob@REDACTED> wrote:
 > > >>
 > > >> Well, the float type in Erlang binaries by itself is big endian, not
 > > >> native endian. This is a bug in Erlang.
 > > >
 > > > This is not a bug. The default for numeric types is big endian. If you
 > > want
 > > > native endian, you must say so:
 > > >
 > > > <<F/native-float>>
 > >
 > > No, this is a bug. <<F/float>> on his platform is not returning big endian.

In a way it is. It takes the byte sequence representation of a float
or double and converts that byte sequence to big endian order.

The problem is that the FPA format isn't consistent with the processor's
normal integer byte ordering rules. So things like the exponent don't
necessarily end up where you'd expect.

 > >
 > 
 > Sorry, I misunderstood you.
 > 
 > In that case, WORDS_BIGENDIAN in config.h seems to be wrong. It should be
 > defined if the
 > processor is big endian (like Sparc), and undefined otherwise.

No, see above.

I've seen many application source codes ported to ARM, and there
is no simple generic "it's little endian" or "it's big endian"
description for the C "double" representation. The only way to
handle it is to use various ARM-specific preprocessor symbols
to enumerate combinations of native endianess and FP format and
handle each combination individually.

That's why the long obsolete FPA format is so insane, and why
every ARM out there should migrate over to soft or hard VFP ASAP.
(Unless it has hard-FPA or hard-Maverick, but few do.)

But there is a bug in Erlang in that it contains code which
assumes standard IEEE FP representation. You can fix that,
or you can declare machines using other formats unsupported.