Punto flotante hexadecimal de IBM

Coma flotante hexadecimal (ahora llamado HFP por IBM) es un formato para codificar números de punto flotante introducido por primera vez en IBM System/ 360, y admitido en máquinas posteriores basadas en esa arquitectura, así como en máquinas que estaban destinadas a ser compatibles con aplicaciones con System/360.

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⁻⁶⁵ a 16⁶³ (aprox. 5,39761 × 10⁻⁷⁹ a 7,237005 × 10⁷⁵).

El número se representa mediante la siguiente fórmula: (−1)^signo × 0.significado × 16^{exponente−64}.

Precisión simple de 32 bits

Un número HFP de precisión simple (llamado "corto" por IBM) se almacena en una palabra de 32 bits:

1		7			24		(Ancho en pedazos)
S	Gastos			Fracción
31	30	...	24	23	...	0	(índice de bits)*
* La documentación IBM numera los bits de izquierda a derecha, de modo que el bit más significativo es designado como bit número 0.

En este formato el bit inicial no se suprime y el bit inicial 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.

Ejemplo

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₁₀ en binario es 1110110.101₂. Este valor se normaliza moviendo el punto de la base hacia la izquierda cuatro bits (un dígito hexadecimal) a la vez hasta que el dígito más a la izquierda sea cero, lo que produce 0,01110110101₂. 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₂.

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⁺². Se añade un sesgo de +64 al exponente (+2), lo que da +66, que es 100 0010₂.

La combinación del signo, el exponente más el sesgo y la fracción normalizada produce esta codificación:

S	Gastos	Fracción
1	100 0010	0111 0110 1010 0000 0000 0000

En otras palabras, el número representado es −0.76A000₁₆ × 16^{66 − 64} = −0.4633789… × 16⁺² = −118,625

Número más grande representable

S	Gastos	Fracción
0	111 1111	1111 1111 1111 1111 1111 1111 1111 1111

El número representado es +0.FFFFFF₁₆ × 16^{127 − 64} = (1 − 16⁻⁶) × 16⁶³ ≈ +7.2370051 × 10⁷⁵

Número normalizado positivo más pequeño

S	Gastos	Fracción
0	000	000 0000 0000 0000 0000 0000

El número representado es +0,1₁₆ × 16^{0 − 64} = 16⁻¹ × 16⁻⁶⁴ ≈ +5,397605 × 10⁻⁷⁹.

Cero

S	Gastos	Fracción
0	000	0000 0000 0000 0000 0000 0000

Cero (0,0) se representa en forma normalizada como todos los bits cero, que aritméticamente es el valor +0,0₁₆ × 16^{0 − 64} = +0 × 16< sup>−64 ≈ +0.000000 × 10⁻⁷⁹ = 0. Dada una fracción de todos los bits cero, cualquier combinación de bits 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.

Problemas de precisión

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 a la "precisión tambaleante" En efecto, esto puede provocar que algunos cálculos sean muy inexactos. Esto ha provocado considerables críticas.

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...₁₆ o 0.0001 1001 1001 1001 1001 1001 1001...₂, es decir:

S	Gastos	Fracción
0	100 0000	0001 1001 1001 1001 1001 1001 1010

Esto 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₁₀(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₁₀(16) + 1 ≈ 8,22) para volver a convertir al mismo valor flotante hexadecimal.

64 bits de doble precisión

El formato HFP de doble precisión (llamado "largo" por IBM) es el mismo que el formato "corto". formato 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):

1		7			56		(Ancho en pedazos)
S	Gastos			Fracción
63	62	...	56	55	...	0	(índice de bits)*
* La documentación IBM numera los bits de izquierda a derecha, de modo que el bit más significativo es designado como bit número 0.

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.

Precisión extendida de 128 bits

Llamado de 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):

Parte de alto orden
1		7			56		(Ancho en pedazos)
S	Gastos			Fracción (alta orden de 14 dígitos)
127	126	...	120	119	...	64	(índice de bits)*
Parte de bajo orden
8					56		(Ancho en pedazos)
No utilizados				Fracción (bajo pedido 14 dígitos)
63	...		56	55	...	0	(índice de bits)*
* La documentación IBM numera los bits de izquierda a derecha, de modo que el bit más significativo es designado como bit número 0.

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.

Operaciones aritméticas

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⁻⁸ = 1. En este caso, el resultado se redondea desde cero.

IEEE 754 en mainframes IBM

A partir del S/390 G5 en 1998, 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 en 2007 usando milicode y en 2008 al IBM System z10 en hardware.

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. Los 16 registros tradicionales de punto flotante se superponen a los nuevos registros vectoriales, de modo que algunos datos se pueden manipular con instrucciones tradicionales de punto flotante o con las instrucciones vectoriales más nuevas.

Usos especiales

El formato IBM HFP se utiliza en:

• SAS 5 Archivos de transporte (.XPT) requeridos por la Administración de Alimentos y Medicamentos (FDA) para nuevas solicitudes de drogas (NDA)
• GRIB (GRIdded Binary) archivos de datos para intercambiar la salida de modelos de predicción meteorológica (formato de punto flotante de una precisión única en la versión actual),
• GDS II (Graphic Database System II) archivos de formato (OASIS es el reemplazo) y
• SEG Y (Society of Exploration Geophysicists Y) format files (IEEE single-precision flotaing-point was added to the format in 2002).

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 del archivo se almacenan utilizando la representación del mainframe 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." El código para el formato de IBM también está disponible en LGPLv2.1.

Sistemas que utilizan el formato de punto flotante de IBM

• IBM System/360 y sucesores
• RCA Spectra 70
• Sistema eléctrico inglés 4
• Minicomputadoras GEC 4000 series
• Computadoras de 16 bits y 32 bits
• SDS Serie Sigma
• Datos Minicomputadoras generales
• Computadoras de la serie ICL 2900
• Siemens 7.700 y 7.500 series mainframes y sucesores

La decisión a favor del punto flotante hexadecimal

El artículo "Arquitectura de IBM System/360" explica la elección porque "la frecuencia del cambio previo, el desbordamiento y la pérdida de precisión posterior al cambio en la adición de punto flotante se reducen sustancialmente con esta elección". Esto permitió un mayor rendimiento para los modelos grandes System/360 y una reducción de costos 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 "Arquitectura de Computadores" por 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 cambios necesarios para la alineación y la normalización, en particular el número de diferentes turnos 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.