Problem with 64 bit FP under ARM

[Martin Sandiford]

Hi Matthias,

On Sat, 23 Aug 2003, Matthias Lang wrote:

> I run erlang r8b on linux on a big-endian PowerPC embedded system
> with floating point emulation:
> 
>  1> <<1.0:64/float>>.
>  <<63,240,0,0,0,0,0,0>>

This looks good to me.  Erlang does some internal massaging to make sure
the ordering is common (BE I think?) regardless of platform.  I believe
I made a error in my previous statement to the effect that this was the
"right" result for a LE machine.  I believe it is correct for the beam
VM.

Usually the difference between LE/BE is a byte by byte swap, highest for
lowest.  I haven't seen quads swapped like this in double before (but I
haven't been looking either).

> I assume you've checked what happened during autoconf, e.g. that you
> have
> 
>   ac_cv_c_bigendian=${ac_cv_c_bigendian=yes}

I'm pretty sure I have this set OK.  The SA1110 is little endian.  
It's pretty easy to tell using (I think) <<1:32/integer>> which
should output <<0,0,0,1>>, but outputs <<1,0,0,0>> if the endianness
is messed up.

> If you provide an example which fails I'll try it.

if <<1.0:64/float>> outputs as above, this matches with my idea of what
should be output.  The compiler uses term_to_binary to convert floating
point constants into binaries, and then writes them out to the .beam
file.  When reading them in on the non-matching machine, they are
back to front quad wise and represent different numbers altogether.

> Are you using the in-kernel FP emulation or the gcc 'soft-float'? See
> also:
> 
>   http://codepoet.org/lists/busybox/2003-June/008547.html

I'm using the in kernel FPE.  Thanks for the tip, maybe the soft-float
thing will provide a solution.

Cheers,
Martin