El punto flotante hexadecimal (ahora llamado HFP por IBM ) es un formato para codificar números de punto flotante introducido por primera vez en las computadoras IBM System/360 y admitido en máquinas posteriores basadas en esa arquitectura, [1] [2] [3] también. como máquinas que estaban destinadas a ser compatibles con las aplicaciones de System/360. [4] [5]
En comparación con el punto flotante IEEE 754 , el formato HFP tiene un significado más largo y un exponente más corto . Todos los formatos HFP tienen 7 bits de exponente con un sesgo de 64. El rango normalizado de números representables es de 16 −65 a 16 63 (aprox. 5,39761 × 10 −79 a 7,237005 × 10 75 ).
El número se representa con la siguiente fórmula: (−1) signo × 0. significado × 16 exponente−64 .
Un número HFP de precisión simple (llamado "corto" por IBM) se almacena en una palabra de 32 bits:
En este formato, el bit inicial no se suprime y el punto de base (hexadecimal) se establece a la izquierda del significado (fracción en la documentación de IBM y las figuras).
Dado que la base es 16, el exponente en esta forma es aproximadamente el doble que el equivalente en IEEE 754; para tener un rango de exponente similar en binario, se necesitarían 9 bits de exponente.
Considere codificar el valor −118,625 como un valor de punto flotante de precisión simple HFP.
El valor es negativo, por lo que el bit de signo es 1.
El valor 118,625 10 en binario es 1110110,101 2 . Este valor se normaliza moviendo el punto de la base cuatro bits hacia la izquierda (un dígito hexadecimal) a la vez hasta que el dígito más a la izquierda sea cero, lo que produce 0,01110110101 2 . Los dígitos restantes del extremo derecho se rellenan con ceros, lo que produce una fracción de 24 bits de .0111 0110 1010 0000 0000 0000 2 .
El valor normalizado movió el punto de la base dos dígitos hexadecimales hacia la izquierda, lo que produjo un multiplicador y un exponente de 16 +2 . Se agrega un sesgo de +64 al exponente (+2), lo que da +66, que es 100 0010 2 .
La combinación del signo, el exponente más el sesgo y la fracción normalizada produce esta codificación:
En otras palabras, el número representado es −0.76A000 16 × 16 66 − 64 = −0.4633789… × 16 +2 = −118.625
El número representado es +0.FFFFFF 16 × 16 127 − 64 = (1 − 16 −6 ) × 16 63 ≈ +7.2370051 × 10 75
El número representado es +0,1 16 × 16 0 − 64 = 16 −1 × 16 −64 ≈ +5,397605 × 10 −79 .
Cero (0,0) se representa en forma normalizada como todos los bits cero, que aritméticamente es el valor +0,0 16 × 16 0 − 64 = +0 × 16 −64 ≈ +0,000000 × 10 −79 = 0. Dada una fracción de todos- bits cero, cualquier combinación de bit de signo positivo o negativo y un exponente sesgado distinto de cero producirá un valor aritméticamente igual a cero. Sin embargo, la forma normalizada generada para cero por el hardware de la CPU es cero en todos los bits. Esto es válido para los tres formatos de precisión de punto flotante. La suma o resta con otros valores de exponentes puede perder precisión en el resultado.
Dado que la base es 16, puede haber hasta tres bits cero a la izquierda en el significado binario. Eso significa que cuando el número se convierte a binario, puede haber tan solo 21 bits de precisión. Debido al efecto de "precisión tambaleante", esto puede provocar que algunos cálculos sean muy inexactos. Esto ha provocado considerables críticas. [6]
Un buen ejemplo de inexactitud es la representación del valor decimal 0,1. No tiene representación binaria o hexadecimal exacta. En formato hexadecimal, se representa como 0.19999999... 16 o 0.0001 1001 1001 1001 1001 1001 1001... 2 , es decir:
Este tiene sólo 21 bits, mientras que la versión binaria tiene 24 bits de precisión.
Seis dígitos hexadecimales de precisión equivalen aproximadamente a seis dígitos decimales (es decir, (6 − 1) log 10 (16) ≈ 6,02). Una conversión de un valor flotante hexadecimal de precisión simple a una cadena decimal requeriría al menos 9 dígitos significativos (es decir, 6 log 10 (16) + 1 ≈ 8,22) para volver a convertir al mismo valor flotante hexadecimal.
El formato HFP de doble precisión (llamado "largo" por IBM) es el mismo que el formato "corto", excepto que el campo de fracción es más ancho y el número de doble precisión se almacena en una palabra doble (8 bytes):
El exponente de este formato cubre sólo aproximadamente una cuarta parte del rango del formato binario IEEE correspondiente.
14 dígitos hexadecimales de precisión equivalen aproximadamente a 17 dígitos decimales. Una conversión de un valor flotante hexadecimal de doble precisión a una cadena decimal requeriría al menos 18 dígitos significativos para volver a convertir al mismo valor flotante hexadecimal.
Llamado precisión extendida por IBM, se agregó un formato HFP de precisión cuádruple a la serie System/370 y estaba disponible en algunos modelos S/360 (S/360-85, -195 y otros por pedido especial o simulados por software del sistema operativo). ). El campo de fracción de precisión extendida es más amplio y el número de precisión extendida se almacena como dos palabras dobles (16 bytes):
28 dígitos hexadecimales de precisión equivalen aproximadamente a 32 dígitos decimales. Una conversión de HFP de precisión extendida a una cadena decimal requeriría al menos 35 dígitos significativos para volver a convertir al mismo valor de HFP. El exponente almacenado en la parte de orden inferior es 14 menor que la parte de orden superior, a menos que sea menor que cero.
Las operaciones aritméticas disponibles son sumar y restar, tanto normalizadas como no normalizadas, y comparar. La prenormalización se realiza en función de la diferencia de exponentes. Multiplica y divide valores no normalizados prenormalizados y trunca el resultado después de un dígito de guardia. Existe una operación de reducción a la mitad para simplificar la división por dos. A partir del ESA/390, existe una operación de raíz cuadrada. Todas las operaciones tienen un dígito de guardia hexadecimal para evitar pérdida de precisión. La mayoría de las operaciones aritméticas se truncan como simples calculadoras de bolsillo. Por lo tanto, 1 − 16 −8 = 1. En este caso, el resultado se redondea desde cero. [7]
A partir del S/390 G5 en 1998, [8] los mainframes de IBM también han incluido unidades binarias de punto flotante IEEE que cumplen con el estándar IEEE 754 para aritmética de punto flotante . El punto flotante decimal IEEE se agregó a IBM System z9 GA2 [9] en 2007 usando milicode [10] y en 2008 al IBM System z10 en hardware. [11]
Los mainframes IBM modernos admiten tres raíces de punto flotante con 3 formatos hexadecimales (HFP), 3 formatos binarios (BFP) y 3 formatos decimales (DFP). Hay dos unidades de punto flotante por núcleo; uno que respalda a HFP y BFP, y otro que respalda a DFP; hay un archivo de registro, FPR, que contiene los 3 formatos. A partir del z13 en 2015, los procesadores agregaron una función vectorial que incluye 32 registros vectoriales, cada uno de 128 bits de ancho; un registro vectorial puede contener dos números de punto flotante de 64 bits o cuatro de 32 bits. [12] Los 16 registros tradicionales de punto flotante se superponen a los nuevos registros vectoriales, por lo que algunos datos pueden manipularse con instrucciones tradicionales de punto flotante o con las instrucciones vectoriales más nuevas.
El formato IBM HFP se utiliza en:
Como IBM es el único proveedor restante de hardware que utiliza el formato HFP, y como las únicas máquinas IBM que admiten ese formato son sus mainframes, pocos formatos de archivo lo requieren. Una excepción es el formato de archivo de transporte SAS 5, que exige la FDA; en ese formato, "Todos los números de punto flotante en el archivo se almacenan usando la representación de la computadora central IBM. [...] La mayoría de las plataformas usan la representación IEEE para números de punto flotante. [...] Para ayudarlo a leer y/ o escribiendo archivos de transporte, proporcionamos rutinas para convertir de representación IEEE (ya sea big endian o little endian) a representación de transporte y viceversa". [13] El código para el formato de IBM también está disponible en LGPLv2.1 . [15]
El artículo "Arquitectura del IBM System/360" explica la elección porque "esta elección reduce sustancialmente la frecuencia del cambio previo, el desbordamiento y la pérdida de precisión posterior al cambio en la adición de punto flotante". [16] Esto permitió un mayor rendimiento para los modelos grandes System/360 y redujo el costo para los pequeños. Los autores eran conscientes del potencial de pérdida de precisión, pero asumieron que esto no sería significativo para las variables de punto flotante de 64 bits. Desafortunadamente, los diseñadores parecen no haber sido conscientes de la Ley de Benford, lo que significa que una gran proporción de números sufrirán una precisión reducida.
El libro "Computer Architecture" de dos de los arquitectos de System/360 cita el estudio de Sweeney de 1958-65 que demostró que el uso de una base mayor que 2 reducía en gran medida el número de turnos necesarios para la alineación y la normalización, en particular el número de turnos diferentes necesarios. . Usaron una base más grande para hacer que las implementaciones se ejecutaran más rápido, y la elección de la base 16 fue natural dados los bytes de 8 bits. La intención era que los flotantes de 32 bits solo se usaran para cálculos que no propagaran errores de redondeo, y que se usara doble precisión de 64 bits para todos los cálculos científicos y de ingeniería. La implementación inicial de doble precisión carecía de un dígito de guardia para permitir un redondeo adecuado, pero esto se cambió poco después de las primeras entregas a los clientes. [17]