The shared code assumes that the IEEE 64-bit pattern will be stored in
memory in the same layout as the same bit pattern held in an int64_t.
For the pattern 0x8877665544332211, the various layouts are (memory
addresses increasing from left to right):
Bigendian: 0x88 0x77 0x66 0x55 0x44 x033 0x22 0x11
Littleendian: 0x11 0x22 0x33 0x44 x055 x066 0x77 0x88
The ARM floating point coprocessor design specifies that doubles are stored
in memory as two 32-bit words, with the first word containing the top 32
bits, the second word the low 32 bits. This is OK until you start using the
littleendian convention for storing the 32-bit words...
FPU spec: ....0x88776655..... ....0x44332211.....
Bigendian ARM: 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11
Littleendian ARM: 0x55 0x66 0x77 0x88 0x11 0x22 0x33 0x44 !!
EPOC32 implemented its ARM floating point emulation to match this
specification, but the C compiler and EPOC32 expect 64-bit integers in the
"natural" order.
memory in the same layout as the same bit pattern held in an int64_t.
For the pattern 0x8877665544332211, the various layouts are (memory
addresses increasing from left to right):
Bigendian: 0x88 0x77 0x66 0x55 0x44 x033 0x22 0x11
Littleendian: 0x11 0x22 0x33 0x44 x055 x066 0x77 0x88
The ARM floating point coprocessor design specifies that doubles are stored
in memory as two 32-bit words, with the first word containing the top 32
bits, the second word the low 32 bits. This is OK until you start using the
littleendian convention for storing the 32-bit words...
FPU spec: ....0x88776655..... ....0x44332211.....
Bigendian ARM: 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11
Littleendian ARM: 0x55 0x66 0x77 0x88 0x11 0x22 0x33 0x44 !!
EPOC32 implemented its ARM floating point emulation to match this
specification, but the C compiler and EPOC32 expect 64-bit integers in the
"natural" order.
- duplicates
-
JDK-4068833 VM assumes that endianness of jlong and double is the same
-
- Closed
-