Re: Issue transfering double over the network on x86_64/arvm8
Duncan Grisby via omniORB-list <[email protected]> Fri, 03 Feb 2023 10:45:09 +0000
| Newsgroups | gmane.comp.corba.omniorb.user |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2023-02-02 at 20:25 +0100, Thomas Braun via omniORB-list wrote: > in cppTango we have a report of something going wrong on the armv8 > (Apple M1) platform [1]. It looks like some endianess issue although > the platform is actually little-endian. > > I suceeded in replicating the issue with an x86_64 server and an > armv8 > client using src/examples/anyExample. I've compiled omniORB 4.2.5 on > MacOSX Ventura and debian bullseye. > > See the garbage output for double on the server. Some ARM CPUs have a strange "mixed-endian" double format, where the 64-bit value is represented as two 32-bit words. The bytes in the 32- bit words are little endian, but the two 32-bit words are in big endian order. I don't think the M1/M2 processors do that bizarre thing, but it looks as though omniORB's build thinks they do, and so rearranges the values incorrectly. If you look in include/omniORB4/CORBA_sysdep.h you'll see this: // __VFP_FP__ means that the floating point format in use is that of the ARM // VFP unit, which is native-endian IEEE-754. #if defined(__arm__) # if defined(__armv5teb__) || defined(__VFP_FP__) # define NO_OMNI_MIXED_ENDIAN_DOUBLE # else # define OMNI_MIXED_ENDIAN_DOUBLE # endif #endif I would have hoped that __VFP_FP__ was defined in Apple's compiler, but this would suggest that it is not. I can check what is defined on an M1 system later today, but if you want to look sooner, that is the place to check. Duncan. -- Duncan Grisby <[email protected]>