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 compatible con máquinas posteriores basadas en esa arquitectura, [1] [2] [3] así como máquinas que fueron diseñadas para ser compatibles con aplicaciones con 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 (aproximadamente 5,39761 × 10 −79 a 7,237005 × 10 75 ).
El número se representa mediante la siguiente fórmula: (−1) signo × 0. significando × 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 de la significación (fracción en la documentación de IBM y las figuras).
Como la base es 16, el exponente en esta forma es aproximadamente el doble de grande que el equivalente en IEEE 754; para tener un rango de exponente similar en binario, se requerirí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 base cuatro bits a la izquierda (un dígito hexadecimal) hasta que el dígito más a la izquierda sea cero, lo que da como resultado 0.01110110101 2 . Los dígitos restantes más a la derecha se rellenan con ceros, lo que da como resultado 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 exponente de 16 +2 . Se agregó un sesgo de +64 al exponente (+2), lo que produjo +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 .
El cero (0,0) se representa en forma normalizada como todos los bits cero, que es aritméticamente el valor +0,0 16 × 16 0 − 64 = +0 × 16 −64 ≈ +0,000000 × 10 −79 = 0. Dada una fracción de todos los 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 todos los bits cero. Esto es cierto para los tres formatos de precisión de punto flotante. La suma o resta con otros valores de exponente puede perder precisión en el resultado.
Como la base es 16, puede haber hasta tres bits cero a la izquierda en el mantis binario. Esto 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 oscilante", esto puede provocar que algunos cálculos sean muy imprecisos. Esto ha provocado muchas críticas. [6]
Un buen ejemplo de la inexactitud es la representación del valor decimal 0,1. No tiene una 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:
Éste 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 "long" por IBM) es el mismo que el formato "short" 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 alrededor de 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 precisión doble a una cadena decimal requeriría al menos 18 dígitos significativos para volver a convertirlo al mismo valor flotante hexadecimal.
IBM llamó a este formato HFP de precisión cuádruple un formato de precisión extendida que se agregó a la serie System/370 y que estaba disponible en algunos modelos S/360 (S/360-85, -195 y otros por pedido especial o simulado por el software del sistema operativo). El campo de fracción de precisión extendida es más ancho 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 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 menos que la parte de orden superior, a menos que este sea menor que cero.
Las operaciones aritméticas disponibles son la suma y la resta, tanto normalizadas como no normalizadas, y la comparación. La prenormalización se realiza en función de la diferencia de exponentes. La multiplicación y la división prenormalizan los valores no normalizados y truncan el resultado después de un dígito de guarda. Existe una operación de división por la mitad para simplificar la división por dos. A partir de ESA/390, existe una operación de raíz cuadrada. Todas las operaciones tienen un dígito de guarda hexadecimal para evitar la pérdida de precisión. La mayoría de las operaciones aritméticas truncan como calculadoras de bolsillo simples. Por lo tanto, 1 − 16 −8 = 1. En este caso, el resultado se redondea a partir de cero. [7]
A partir del S/390 G5 en 1998, [8] los mainframes de IBM también han incluido unidades de punto flotante binario IEEE que cumplen con el estándar IEEE 754 para aritmética de punto flotante . El punto flotante decimal IEEE se agregó al IBM System z9 GA2 [9] en 2007 utilizando milicode [10] y en 2008 al IBM System z10 en hardware. [11]
Los mainframes IBM modernos admiten tres bases de coma flotante con tres formatos hexadecimales (HFP), tres formatos binarios (BFP) y tres formatos decimales (DFP). Hay dos unidades de coma flotante por núcleo; una que admite HFP y BFP, y otra que admite DFP; hay un archivo de registro, FPRs, que contiene los tres formatos. A partir del z13 en 2015, los procesadores han agregado 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 coma flotante de 64 bits o cuatro de 32 bits. [12] Los 16 registros de coma flotante tradicionales se superponen a los nuevos registros vectoriales, de modo que algunos datos se pueden manipular con instrucciones de coma flotante tradicionales 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 la FDA exige; en ese formato, "Todos los números de punto flotante en el archivo se almacenan utilizando la representación del mainframe de IBM. [...] La mayoría de las plataformas utilizan la representación IEEE para números de punto flotante. [...] Para ayudarlo a leer y/o escribir archivos de transporte, proporcionamos rutinas para convertir de la representación IEEE (ya sea big endian o little endian) a la 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 que la elección se debe a que "la frecuencia de predesplazamiento, desbordamiento y pérdida de precisión posterior al desplazamiento en la suma de coma flotante se reduce sustancialmente con esta elección". [16] Esto permitió un mayor rendimiento para los modelos grandes del System/360 y redujo el costo para los pequeños. Los autores eran conscientes de la posibilidad de pérdida de precisión, pero asumieron que esto no sería significativo para las variables de coma flotante de 64 bits. Desafortunadamente, los diseñadores parecen no haber sido conscientes de la Ley de Benford , que significa que una gran proporción de números sufrirán una reducción de precisión.
El libro "Computer Architecture" de dos de los arquitectos de System/360 cita el estudio de Sweeney de 1958-65 que mostraba que el uso de una base mayor que 2 reducía en gran medida el número de desplazamientos necesarios para la alineación y la normalización, en particular el número de desplazamientos diferentes necesarios. Utilizaron una base mayor para 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 números flotantes de 32 bits solo se utilizaran para cálculos que no propagaran errores de redondeo, y se utilizara la doble precisión de 64 bits para todos los cálculos científicos y de ingeniería. La implementación inicial de la doble precisión carecía de un dígito de guarda para permitir un redondeo adecuado, pero esto se cambió poco después de las primeras entregas a los clientes. [17]