2

Here is an image showing an output of the same program in intel and then in ARM:

http://screencast.com/t/1eA64D4rF

Both show output from reading a binary file with the numbers in the first column being of double precision floating point format. Why is it that I am unable to obtain the correct result (like in the case of intel -- 41784.998495, 41784.998623) vs (-8.1974E+204f etc) on the ARM environment?

The arm processor I am using is:

Processor       : ARM926EJ-Sid(wb) rev 0 (v5l)

BogoMIPS        : 331.77

Features        : swp half thumb fastmult edsp java

CPU implementer : 0x41

CPU architecture: 5TEJ

CPU variant     : 0x0

CPU part        : 0x926

CPU revision    : 0

Cache type      : write-back

Cache clean     : cp15 c7 ops

Cache lockdown  : format C

Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 1
D line length   : 32
D sets          : 1024

Hardware        : MV-88fxx81
Revision        : 0000
Serial          : 0000000000000000

My compile option on the ARM: g++ -Wall SC_SCID.cpp

How can I read the double precision type correctly on this processor? Are there any compiler options that I need to enable to correctly process double precision numbers on the ARM?

Undo
  • 25,519
  • 37
  • 106
  • 129
valueRunner
  • 23
  • 3
  • possible duplicate of [Would float point format be affected by big-endian and little endian?](http://stackoverflow.com/questions/5242589/would-float-point-format-be-affected-by-big-endian-and-little-endian) – artless noise Jun 24 '14 at 14:40

2 Answers2

0

The difference between numbers like 41784.998495 and -8.1974E+204 is most likely a byte ordering issue -- Intel processors are little-endian, while ARMs are big-endian. So if you write a binary file on one and want to read it on the other, you'll need to byte-swap the values.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • 2
    "ARMs are big-endian" - huh? ARM CPUs are _bi_-endian, but are LE by default - not many systems run them in BE mode (although I'm not saying this _isn't_ one of them). – Notlikethat Jun 24 '14 at 00:09
  • Thank you both for your inputs. The solution was indeed to rearrange the byte order. `double swap(double d)` `{` `double a;` `unsigned char *dst = (unsigned char *)&a;` `unsigned char *src = (unsigned char *)&d;` `dst[0] = src[4];` `dst[1] = src[5];` `dst[2] = src[6];` `dst[3] = src[7];` `dst[4] = src[0];` `dst[5] = src[1];` `dst[6] = src[2];` `dst[7] = src[3];` ` return a;` `}` [link] (http://www.screencast.com/t/Qqf40iy4Kc) – valueRunner Jun 24 '14 at 02:15
  • More of a Doubleword swap. – valueRunner Jun 24 '14 at 12:29
0

NB: This is a wiki answer; anyone may edit.

As per wikipedia, the ARM softfp emulation of double uses a mix of big and little endian. The native format of the ARM926EJ is definitely little endian for integer types.

Read more in the question Would float point format be affected by big-endian and little endian?

Community
  • 1
  • 1
artless noise
  • 21,212
  • 6
  • 68
  • 105