soporte de numbers flotantes IEEE 754 subnormal en dispositivos iOS ARM (iPhone 4)

Al portar una aplicación de Linux x86 a iOS ARM (iPhone 4), he descubierto una diferencia en el comportamiento en aritmética de coma flotante y valores pequeños.

Los numbers de punto flotante de 64 bits (doble) menores que [+/-] 2.2250738585072014E-308 se denominan numbers normales / desnormalizados / subnormales en los estándares IEEE 754-1985 / IEEE 754-2008 .

En iPhone 4, estos numbers pequeños se tratan como cero (0), mientras que en x86, los numbers subnormales se pueden usar para el cálculo.

No pude encontrar ninguna explicación con respecto a la conformidad con los estándares IEEE-754 en la documentation de Apple. Página manual de Mac OS X Para flotante (3) .

Pero gracias a algunas respuestas sobre Stack Overflow ( comportamiento de cero a cero en la aritmética de punto flotante , Doble vs flotante en el iPhone ), he encontrado algunas pistas.

Según algunas búsquedas, parece que el coprocesador matemático VFP (o NEON ) utilizado a lo largo del núcleo ARM está usando el modo Flush-To-Zero (FTZ) (por ejemplo, los valores subnormales se convierten a 0 en la salida) y Denormals-Are-Zero ( DAZ) (por ejemplo, los valores subnormales se convierten a 0 cuando se usan como parameters de input) para proporcionar un cómputo rápido de IEEE 754 manipulado por hardware.

  • Cumplimiento total de IEEE754 con el código de soporte de ARM
  • Modo Run-Fast para cumplimiento cercano a IEEE754 (solo hardware)

Una buena explicación sobre FTZ y DAZ se puede encontrar en x87 y SSE Floating Point Assists en IA-32: Flush-to-Zero (FTZ) y Denormals-Are-Zero (DAZ) :

Los modos FTZ y DAZ manejan los casos cuando se producen datos de punto flotante no válidos o se procesan con condiciones desbordadas o desnudas. […] La diferencia entre un número que maneja FTZ y DAZ es muy sutil. FTZ maneja condiciones de desbordamiento mientras DAZ maneja denormals. Se produce una condición de desbordamiento cuando un cálculo resulta en una situación irregular. En este caso, el modo FTZ establece la salida a cero. DAZ corrige los casos cuando los denormals se utilizan como input, ya sea como constantes o al leer la memory inválida en loggings. El modo DAZ establece las inputs del cálculo en cero antes del cálculo. Se puede decir que FTZ maneja [salida] mientras DAZ maneja [input].

Las únicas cosas sobre FTZ en el sitio de desarrolladores de Apple parecen estar en la Guía de llamadas de funciones ABI de iOS :

Registro de estado de VFP | FPSCR | Especial | Los códigos de condición bits (28-31) y los bits de saturación (0-4) no se conservan mediante llamadas de function. El control de exception (8-12), el modo de networkingondeo (22-23) y los bits de nivel cero (24) deben modificarse solo por rutinas específicas que afectan el estado de la aplicación (incluidas las funciones de la API del marco). La longitud del vector corto (16-18) y la zancada (20-21) bits deben ser cero en la input y salida de la function. Todos los demás bits no deben modificarse.

De acuerdo con el Manual de reference técnica ARM1176JZF-S, 18.5 Modos de funcionamiento (primer procesador de iPhone), el VFP puede configurarse para admitir completamente IEEE 754 (aritmética sub normal), pero en este caso requerirá algo de soporte de software (atrapando en kernel a cómputo en software).

Nota: También he leído las páginas de comparación de puerto flotante ARM y VFP de Debian.

Mis preguntas son:

  • ¿Dónde se pueden encontrar respuestas definitivas sobre el event handling numbers subnormales en dispositivos iOS?

  • ¿Se puede configurar el sistema iOS para que brinde soporte para el número subnormal sin pedirle al comstackdor que produzca solo el código de punto flotante de software completo?

Gracias.

¿Se puede configurar el sistema iOS para que brinde soporte para el número subnormal sin pedirle al comstackdor que produzca solo el código de punto flotante de software completo?

Sí. Esto se puede lograr configurando el bit FZ en el FPSCR a cero:

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

Tenga en count que esto puede causar disminuciones significativas en el performance de la aplicación cuando se encuentran cantidades apreciables de valores normales. Puede (y debería) restablecer el estado de punto flotante pnetworkingeterminado antes de realizar llamadas a cualquier código que no garantice una ABI para funcionar correctamente en modos no pnetworkingeterminados:

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

Por favor, presente un informe de error para solicitar que se proporcione mejor documentation para los modos de operación FP en iOS.

 •Where can one find definitive answers regarding subnormal numbers 

manejo a través de dispositivos iOS?

Ya has encontrado tu respuesta. Es de esperar que el ARM no tenga las mismas capacidades de punto flotante.

• ¿Se puede configurar el sistema iOS para que brinde soporte para el número subnormal sin pedirle al comstackdor que produzca solo el código de punto flotante de software completo?

No lo creo, al less eso espero, para get numbers diferentes usando el mismo valor.

Intereting Posts