在iOS设备的ARM低于正常IEEE 754浮点数支持（iPhone 4） [英] subnormal IEEE 754 floating point numbers support on iOS ARM devices (iPhone 4)

问题描述

虽然从移植Linux x86的应用程序到iOS ARM（iPhone 4），我发现
浮点算术和小值的行为差异。

64位浮点数（双）小于[ +/-] 2.2250738585072014E-308被称为非正规/非规范化/低于正常号码的的 IEEE 754-1985 /的 IEEE 754-2008标准

在iPhone 4，这样小的数字被视为零（0），而在x86，次正规数可用于计算。

我没能找到有关符合IEEE-754标准对苹果的文档<一个任何解释href=\"http://developer.apple.com/library/ios/#documentation/System/Conceptual/ManPages_iPhoneOS/man3/float.3.html\"相对=nofollow> Mac OS X的手册对于float（3）。

但由于对堆栈溢出一些答案（<一个href=\"http://stackoverflow.com/questions/2083550/flush-to-zero-behavior-in-floating-point-arithmetic\">flush-to-zero行为浮点运算，双VS浮在iPhone ），我已经找到了一些线索。

据一些搜索，似乎 VFP （或 NEON ）数学协处理器使用同花顺-to-零（FTZ）模式（例如低于正常数值在输出转换为0）和非正规数为零（DAZ）模式，提供处理IEEE牛逼的（作为输入参数使用时，如低于正常值转换为0） 754计算。

  

  
• 全IEEE754符合ARM的支持code

  
• 近IEEE754合规运行快速模式（仅硬件）

  

在保税区和DAZ一个很好的解释可以发现
<一href=\"http://software.intel.com/en-us/articles/x87-and-sse-floating-point-assists-in-ia-32-flush-to-zero-ftz-and-denormals-are-zero-daz/\"相对=nofollow>的x87和SSE浮点协助在IA-32：冲洗到零（FTZ）和非正规数为零（DAZ）：

  当出现无效的浮点数据，或者是

保税区和DAZ模式两种处理情况
  下溢或者非正规的条件处理。 [...]。一个数之间的差
  由保税区处理，DAZ很微妙。保税区处理而溢条件
  DAZ处理非正规。当计算结果是一个发生下溢条件
  非规格化。在这种情况下，自由贸易区模式设置输出为零。 DAZ修复的情况下，当
  非规格化被用作输入，无论是作为常数或通过读取无效存储器进
  寄存器。 DAZ模式计算之前设置的计算的输入为零。保税区
  然后可以说，以处理[输出]同时DAZ手柄[输入]。

有关保税区在苹果的开发者网站的唯一的事情似乎是在<一个href=\"http://developer.apple.com/library/ios/#documentation/X$c$c/Conceptual/iPhoneOSABIReference/Articles/ARMv6FunctionCallingConventions.html\"相对=nofollow>的iOS ABI函数调用指南：

  

VFP状态寄存器|
  FPSCR |
  专题|
  条件code位（28-31）和饱和度位（0-4）是不是函数调用pserved $ P $。异常控制（8-12），舍入模式（22-23），和刷新到零（24）的位应只影响应用程序状态的具体程序（包括框架API函数修改）。短向量长度（16-18）和步（20-21）位必须在函数入口和出口为零。所有其他位不能修改。

根据 ARM1176JZF-S技术参考手册，18.5
操作（第一个iPhone处理器）的模式下，VFP可经配置以充分支持IEEE 754（分正常算术），但在这种情况下，将需要一些软件支持（捕集到内核来计算软件）。

请注意：我也看到了Debian的 ARM硬浮法港口并的 VFP比较页

我的问题是：

• 在哪里可以找到有关次正规数在iOS设备处理确切的答案？




• 一个可以设置IOS系统，为次正规数的支持，而不要求编译器生成唯一的完整的软件浮点code？

感谢。

解决方案

  

可以在一个设定的iOS系统，为次正规数的支持，而不要求编译器生成唯一的完整的软件浮点code？

是的。这可以通过在FPSCR中的FZ位设置为零来实现：

 静态内嵌无效DisableFZ（）
{
    __asm​​__挥发性（VMRS R0，FPSCR \\ n
                     BIC R0，$（1 LT;＆LT; 24）\\ n
                     VMSR FPSCR，R0：R0）;
}
 

请注意，这可能会导致应用程序的性能显著放缓遇到非正规值的AP preciable数量时。您可以（也应该）打电话到任何code，不使一个ABI保证在非缺省模式下正常工作之前，浮点状态恢复默认的：

 静态内嵌无效RestoreFZ（）{
    __asm​​__挥发性（VMRS R0，FPSCR \\ n
                     奥尔R0，$（1 LT;＆LT; 24）\\ n
                     VMSR FPSCR，R0：R0）;
}
 

请提交 bug报告来要求更好的文档是FP操作在iOS的模式提供。

While porting an application from Linux x86 to iOS ARM (iPhone 4), I've discovered a difference in behavior on floating point arithmetics and small values.

64bits floating point numbers (double) smaller than [+/-]2.2250738585072014E-308 are called denormal/denormalized/subnormal numbers in the IEEE 754-1985/IEEE 754-2008 standards.

On iPhone 4, such small numbers are treated as zero (0), while on x86, subnormal numbers can be used for computation.

I wasn't able to find any explanation regarding conformance to IEEE-754 standards on Apple's documentation Mac OS X Manual Page For float(3).

But thanks to some answers on Stack Overflow ( flush-to-zero behavior in floating-point arithmetic , Double vs float on the iPhone ), I have found some clues.

According to some searches, it seems the VFP (or NEON) math coprocessor used along the ARM core is using Flush-To-Zero (FTZ) mode (e.g. subnormal values are converted to 0 at the output) and Denormals-Are-Zero (DAZ) mode (e.g. subnormal values are converted to 0 when used as input parameters) to provide fast hardware handled IEEE 754 computation.

• Full IEEE754 compliance with ARM support code
• Run-Fast mode for near IEEE754 compliance (hardware only)

A good explanation on FTZ and DAZ can be found in x87 and SSE Floating Point Assists in IA-32: Flush-To-Zero (FTZ) and Denormals-Are-Zero (DAZ):

FTZ and DAZ modes both handle the cases when invalid floating-point data occurs or is processed with underflow or denormal conditions. [...]. The difference between a number that is handled by FTZ and DAZ is very subtle. FTZ handles underflow conditions while DAZ handles denormals. An underflow condition occurs when a computation results in a denormal. In this case, FTZ mode sets the output to zero. DAZ fixes the cases when denormals are used as input, either as constants or by reading invalid memory into registers. DAZ mode sets the inputs of the calculation to zero before computation. FTZ can then be said to handle [output] while DAZ handles [input].

The only things about FTZ on Apple's developer site seems to be in iOS ABI Function Call Guide :

VFP status register | FPSCR | Special | Condition code bits (28-31) and saturation bits (0-4) are not preserved by function calls. Exception control (8-12), rounding mode (22-23), and flush-to-zero (24) bits should be modified only by specific routines that affect the application state (including framework API functions). Short vector length (16-18) and stride (20-21) bits must be zero on function entry and exit. All other bits must not be modified.

According to ARM1176JZF-S Technical Reference Manual, 18.5 Modes of operation (first iPhone processor), the VFP can be configured to fully support IEEE 754 (sub normal arithmetic), but in this case it will require some software support (trapping into kernel to compute in software).

Note: I have also read Debian's ARM Hard Float Port and VFP comparison pages.

My questions are :

• Where can one find definitive answers regarding subnormal numbers handling across iOS devices ?

• Can one set the iOS system to provide support for subnormal number without asking the compiler to produce only full software floating point code ?

Thanks.

解决方案

Can one set the iOS system to provide support for subnormal number without asking the compiler to produce only full software floating point code?

Yes. This can be achieved by setting the FZ bit in the FPSCR to zero:

static inline void DisableFZ( )
{
    __asm__ volatile("vmrs r0, fpscr\n"
                     "bic r0, $(1 << 24)\n"
                     "vmsr fpscr, r0" : : : "r0");
}

Note that this can cause significant slowdowns in application performance when appreciable quantities of denormal values are encountered. You can (and should) restore the default floating-point state before making calls into any code that does not make an ABI guarantee to work properly in non-default modes:

static inline void RestoreFZ( ) {
    __asm__ volatile("vmrs r0, fpscr\n"
                     "orr r0, $(1 << 24)\n"
                     "vmsr fpscr, r0" : : : "r0");
}

Please file a bug report to request that better documentation be provided for the modes of FP operation in iOS.

这篇关于在iOS设备的ARM低于正常IEEE 754浮点数支持（iPhone 4）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！