在ARM平台上正确检测混合字节序浮点格式 [英] Correctly detect mixed-endian floating point format on ARM platform
问题描述
我最近遇到了一个第三方库的问题，该库正在使用以下代码来测试ARM平台上的混合字节序浮点格式:
I recently ran into an issue with a third party library that was using the following code to test for mixed-endian floating-point format on ARM platforms:
#if defined(__arm__) && !(__ARM_EABI__)
此检查在Android平台上错误地检测到混合字节序格式，但在iOS平台上正常工作.经过一番研究，我发现了 debian ArmEabiPort文档，该文档在 GCC预处理器宏中包含以下内容以进行浮动点部分(强调我的):
This check was incorrectly detecting mixed-endian format on Android platforms but worked correctly on iOS platforms. After some research I found the debian ArmEabiPort document which contains the following in the GCC preprocessor macros for floating point section which says(emphasis mine):
将代码移植到"armel"时，以下预处理器宏为 有趣:
When porting code to "armel", the following preprocessor macros are interesting:
-
__ VFP_FP__表示所使用的浮点格式是ARM VFP单元的格式，它是本机端字节的IEEE-754.
__VFP_FP__ means that the floating point format in use is that of the ARM VFP unit, which is native-endian IEEE-754.
__ MAVERICK__意味着浮点格式是Cirrus Logic MaverickCrunch的格式，它也是IEEE-754，始终为低位优先.
__MAVERICK__ means that the floating point format is that of the Cirrus Logic MaverickCrunch, which is also IEEE-754 and is always little-endian.
__ SOFTFP__意味着将为浮点数学运算生成库调用，而不是浮点指令，以便代码将在没有FPU的处理器上运行.
__SOFTFP__ means that instead of floating point instructions, library calls are being generated for floating point math operations so that the code will run on a processor without an FPU.
__ VFP_FP__和__MAVERICK__是互斥的. 如果未设置任何值，则表示使用的浮点格式是FPA单元的旧混合尾数.
__VFP_FP__ and __MAVERICK__ are mutually exclusive. If neither is set, that means the floating point format in use is the old mixed-endian 45670123 format of the FPA unit.
对于我们的特定情况，将检查更新为以下内容可以解决问题:
For our specific case updating the check to the following fixed the problem:
#if defined(__arm__) && !(__VFP_FP__)
，并且可在Android和iOS平台上使用.尽管从文档中可以更正确地进行检查:
and works on both Android and iOS platforms. Although from the document the more correct check would be:
#if defined(__arm__) && !(__VFP_FP__) && !(__MAVERICK__)
我们想将补丁提交给第三方，但考虑到旧支票确实对提交该提议的人有效，并且查找文档有多困难，我觉得我没有足够的信息来获取此补丁正确的.
We would like to submit a patch back to the third-party but considering the old check did work for the person who submitted it and how difficult it is to find documentation I don't feel like I have enough information to get this correct.
是否有上次检查未命中的情况? debian文档专门介绍了gcc，这些宏的可移植性如何?
Are there cases the last check misses? The debian document specifically covers gcc, how portable are these macros?
更新
基于无意杂音的有益评论，问题可归结为:
Based on the helpful comments from artless noise the question boils down to:
__ARM_EABI__宏检查是另一个用户引入的补丁程序，用于检查混合字节序浮点格式.因此，显然存在此宏适用的系统，这些系统是什么? __VFP_FP__宏会覆盖这些系统吗?还是我也需要考虑该宏，以防止在提交补丁时破坏现有用户.
The __ARM_EABI__ macro check was introduced as a patch by another user to check for mixed-endian floating point format. So apparently there are systems that this macro works for, what systems are those? Would the __VFP_FP__ macro cover those systems or do I need to take that macro into account as well to prevent breaking existing users when I submit a patch.
推荐答案
您还需要检查以确保您不在软浮动工具链上，因为软浮动库没有混合使用-endian问题:
You'll also want to check to make sure you aren't on a soft-float toolchain, as the soft-float libraries don't have the mixed-endian issue:
#if defined(arm) && !defined(__SOFTFP__) && !defined(__VFP_FP__) && !defined(__MAVERICK__)
关于编译器支持-它们应该在clang中工作，但是显然，商业ARM编译器将完全做其他事情.
As to compiler support -- these should work in clang, but obviously, the commercial ARM compilers will do something else entirely.
这篇关于在ARM平台上正确检测混合字节序浮点格式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
