IBM hexadecimal floatingpoint
From Wikipedia the free encyclopedia
Floatingpoint formats 

IEEE 754 

Other 
Alternatives 
Hexadecimal floating point (now called HFP by IBM) is a format for encoding floatingpoint numbers first introduced on the IBM System/360 computers, and supported on subsequent machines based on that architecture,^{[1]}^{[2]}^{[3]} as well as machines which were intended to be applicationcompatible with System/360.^{[4]}^{[5]}
In comparison to IEEE 754 floating point, the HFP format has a longer significand, and a shorter exponent. All HFP formats have 7 bits of exponent with a bias of 64. The normalized range of representable numbers is from 16^{−65} to 16^{63} (approx. 5.39761 × 10^{−79} to 7.237005 × 10^{75}).
The number is represented as the following formula: (−1)^{sign} × 0.significand × 16^{exponent−64}.
Singleprecision 32bit[edit]
A singleprecision HFP number (called "short" by IBM) is stored in a 32bit word:
1 7 24 (width in bits) S Exp Fraction 31 30 ... 24 23 ... 0 (bit index)* * IBM documentation numbers the bits from left to right, so that the most significant bit is designated as bit number 0.
In this format the initial bit is not suppressed, and the radix (hexadecimal) point is set to the left of the significand (fraction in IBM documentation and the figures).
Since the base is 16, the exponent in this form is about twice as large as the equivalent in IEEE 754, in order to have similar exponent range in binary, 9 exponent bits would be required.
Example[edit]
Consider encoding the value −118.625 as an HFP singleprecision floatingpoint value.
The value is negative, so the sign bit is 1.
The value 118.625_{10} in binary is 1110110.101_{2}. This value is normalized by moving the radix point left four bits (one hexadecimal digit) at a time until the leftmost digit is zero, yielding 0.01110110101_{2}. The remaining rightmost digits are padded with zeros, yielding a 24bit fraction of .0111 0110 1010 0000 0000 0000_{2}.
The normalized value moved the radix point two hexadecimal digits to the left, yielding a multiplier and exponent of 16^{+2}. A bias of +64 is added to the exponent (+2), yielding +66, which is 100 0010_{2}.
Combining the sign, exponent plus bias, and normalized fraction produces this encoding:
S Exp Fraction 1 100 0010 0111 0110 1010 0000 0000 0000
In other words, the number represented is −0.76A000_{16} × 16^{66 − 64} = −0.4633789… × 16^{+2} = −118.625
Largest representable number[edit]
S Exp Fraction 0 111 1111 1111 1111 1111 1111 1111 1111
The number represented is +0.FFFFFF_{16} × 16^{127 − 64} = (1 − 16^{−6}) × 16^{63} ≈ +7.2370051 × 10^{75}
Smallest positive normalized number[edit]
S Exp Fraction 0 000 0000 0001 0000 0000 0000 0000 0000
The number represented is +0.1_{16} × 16^{0 − 64} = 16^{−1} × 16^{−64} ≈ +5.397605 × 10^{−79}.
Zero[edit]
S Exp Fraction 0 000 0000 0000 0000 0000 0000 0000 0000
Zero (0.0) is represented in normalized form as all zero bits, which is arithmetically the value +0.0_{16} × 16^{0 − 64} = +0 × 16^{−64} ≈ +0.000000 × 10^{−79} = 0. Given a fraction of allbits zero, any combination of positive or negative sign bit and a nonzero biased exponent will yield a value arithmetically equal to zero. However, the normalized form generated for zero by CPU hardware is allbits zero. This is true for all three floatingpoint precision formats. Addition or subtraction with other exponent values can lose precision in the result.
Precision issues[edit]
Since the base is 16, there can be up to three leading zero bits in the binary significand. That means when the number is converted into binary, there can be as few as 21 bits of precision. Because of the "wobbling precision" effect, this can cause some calculations to be very inaccurate. This has caused considerable criticism.^{[6]}
A good example of the inaccuracy is representation of decimal value 0.1. It has no exact binary or hexadecimal representation. In hexadecimal format, it is represented as 0.19999999..._{16} or 0.0001 1001 1001 1001 1001 1001 1001..._{2}, that is:
S Exp Fraction 0 100 0000 0001 1001 1001 1001 1001 1010
This has only 21 bits, whereas the binary version has 24 bits of precision.
Six hexadecimal digits of precision is roughly equivalent to six decimal digits (i.e. (6 − 1) log_{10}(16) ≈ 6.02). A conversion of single precision hexadecimal float to decimal string would require at least 9 significant digits (i.e. 6 log_{10}(16) + 1 ≈ 8.22) in order to convert back to the same hexadecimal float value.
Doubleprecision 64bit[edit]
The doubleprecision HFP format (called "long" by IBM) is the same as the "short" format except that the fraction field is wider and the doubleprecision number is stored in a double word (8 bytes):
1 7 56 (width in bits) S Exp Fraction 63 62 ... 56 55 ... 0 (bit index)* * IBM documentation numbers the bits from left to right, so that the most significant bit is designated as bit number 0.
The exponent for this format covers only about a quarter of the range as the corresponding IEEE binary format.
14 hexadecimal digits of precision is roughly equivalent to 17 decimal digits. A conversion of double precision hexadecimal float to decimal string would require at least 18 significant digits in order to convert back to the same hexadecimal float value.
Extendedprecision 128bit[edit]
Called extendedprecision by IBM, a quadrupleprecision HFP format was added to the System/370 series and was available on some S/360 models (S/36085, 195, and others by special request or simulated by OS software). The extendedprecision fraction field is wider, and the extendedprecision number is stored as two double words (16 bytes):
Highorder part 1 7 56 (width in bits) S Exp Fraction (highorder 14 digits) 127 126 ... 120 119 ... 64 (bit index)* Loworder part 8 56 (width in bits) Unused Fraction (loworder 14 digits) 63 ... 56 55 ... 0 (bit index)* * IBM documentation numbers the bits from left to right, so that the most significant bit is designated as bit number 0.
28 hexadecimal digits of precision is roughly equivalent to 32 decimal digits. A conversion of extended precision HFP to decimal string would require at least 35 significant digits in order to convert back to the same HFP value. The stored exponent in the loworder part is 14 less than the highorder part, unless this would be less than zero.
Arithmetic operations[edit]
Available arithmetic operations are add and subtract, both normalized and unnormalized, and compare. Prenormalization is done based on the exponent difference. Multiply and divide prenormalize unnormalized values, and truncate the result after one guard digit. There is a halve operation to simplify dividing by two. Starting in ESA/390, there is a square root operation. All operations have one hexadecimal guard digit to avoid precision loss. Most arithmetic operations truncate like simple pocket calculators. Therefore, 1 − 16^{−8} = 1. In this case, the result is rounded away from zero.^{[7]}
IEEE 754 on IBM mainframes[edit]
Starting with the S/390 G5 in 1998,^{[8]} IBM mainframes have also included IEEE binary floatingpoint units which conform to the IEEE 754 Standard for FloatingPoint Arithmetic. IEEE decimal floatingpoint was added to IBM System z9 GA2^{[9]} in 2007 using millicode^{[10]} and in 2008 to the IBM System z10 in hardware.^{[11]}
Modern IBM mainframes support three floatingpoint radices with 3 hexadecimal (HFP) formats, 3 binary (BFP) formats, and 3 decimal (DFP) formats. There are two floatingpoint units per core; one supporting HFP and BFP, and one supporting DFP; there is one register file, FPRs, which holds all 3 formats. Starting with the z13 in 2015, processors have added a vector facility that includes 32 vector registers, each 128 bits wide; a vector register can contain two 64bit or four 32bit floatingpoint numbers.^{[12]} The traditional 16 floatingpoint registers are overlaid on the new vector registers so some data can be manipulated with traditional floatingpoint instructions or with the newer vector instructions.
Special uses[edit]
The IBM HFP format is used in:
 SAS 5 Transport files (.XPT) as required by the Food and Drug Administration (FDA) for New Drug Application (NDA) study submissions,^{[13]}
 GRIB (GRIdded Binary) data files to exchange the output of weather prediction models (IEEE singleprecision floatingpoint format in current version),
 GDS II (Graphic Database System II) format files (OASIS is the replacement), and
 SEG Y (Society of Exploration Geophysicists Y) format files (IEEE singleprecision floatingpoint was added to the format in 2002).^{[14]}
As IBM is the only remaining provider of hardware using the HFP format, and as the only IBM machines that support that format are their mainframes, few file formats require it. One exception is the SAS 5 Transport file format, which the FDA requires; in that format, "All floatingpoint numbers in the file are stored using the IBM mainframe representation. [...] Most platforms use the IEEE representation for floatingpoint numbers. [...] To assist you in reading and/or writing transport files, we are providing routines to convert from IEEE representation (either big endian or little endian) to transport representation and back again."^{[13]} Code for IBM's format is also available under LGPLv2.1.^{[15]}
Systems that use the IBM floatingpoint format[edit]
 IBM System/360 and successors
 RCA Spectra 70
 English Electric System 4
 GEC 4000 series minicomputers
 Interdata 16 and 32bit computers
 SDS Sigma series
 Data General minicomputers
 ICL 2900 Series computers
 Siemens 7.700 and 7.500 series mainframes and successors
The decision for hexadecimal floatingpoint[edit]
The article "Architecture of the IBM System/360" explains the choice as being because "the frequency of preshift, overflow, and precisionloss postshift on floatingpoint addition are substantially reduced by this choice."^{[16]} This allowed higher performance for the large System/360 models, and reduced cost for the small ones. The authors were aware of the potential for precision loss, but assumed that this would not be significant for 64bit floatingpoint variables. Unfortunately, the designers seem not to have been aware of Benford's Law which means that a large proportion of numbers will suffer reduced precision.
The book "Computer Architecture" by two of the System/360 architects quotes Sweeney's study of 195865 which showed that using a base greater than 2 greatly reduced the number of shifts required for alignment and normalisation, in particular the number of different shifts needed. They used a larger base to make the implementations run faster, and the choice of base 16 was natural given 8bit bytes. The intention was that 32bit floats would only be used for calculations that would not propagate rounding errors, and 64bit double precision would be used for all scientific and engineering calculations. The initial implementation of double precision lacked a guard digit to allow proper rounding, but this was changed soon after the first customer deliveries.^{[17]}
See also[edit]
References[edit]
 ^ IBM System/360 Principles of Operation, IBM Publication A2268216, Seventh Edition (January 13, 1967), pp.4150
 ^ IBM System/370 Principles of Operation, IBM Publication GA2270004, Fifth Edition (September 1, 1975), pp.157170
 ^ z/Architecture Principles of Operation, IBM Publication SA22783201, Second Edition (October, 2001), chapter 9 ff.
 ^ Xerox Data Systems (Oct 1973). Xerox SIGMA 7 Computer Reference Manyal. p. 48. Retrieved Nov 13, 2020.
 ^ RCA (Mar 1966). Spectra 70 processors: 35 45 55 (PDF). p. 184. Retrieved Nov 13, 2020.
 ^ Warren Jr., Henry S. (2013) [2002]. "The Distribution of Leading Digits". Hacker's Delight (2 ed.). Addison Wesley  Pearson Education, Inc. pp. 385–387. ISBN 9780321842688. 0321842685.
 ^ ESA/390 Enhanced Floating Point Support: An Overview
 ^ Schwarz, E. M.; Krygowski, C. A. (September 1999). "The S/390 G5 floatingpoint unit". IBM Journal of Research and Development. 43 (5.6): 707–721. doi:10.1147/rd.435.0707.
 ^ Duale, A. Y.; Decker, M. H.; Zipperer, H.G.; Aharoni, M.; Bohizic, T. J. (January 2007). "Decimal floatingpoint in z9: An implementation and testing perspective". IBM Journal of Research and Development. 51 (1.2): 217–227. CiteSeerX 10.1.1.123.9055. doi:10.1147/rd.511.0217.
 ^ Heller, L. C.; Farrell, M. S. (May 2004). "Millicode in an IBM zSeries processor". IBM Journal of Research and Development. 48 (3.4): 425–434. CiteSeerX 10.1.1.641.1164. doi:10.1147/rd.483.0425.
 ^ Schwarz, E. M.; Kapernick, J. S.; Cowlishaw, M. F. (January 2009). "Decimal floatingpoint support on the IBM System z10 processor". IBM Journal of Research and Development. 53 (1): 4:1–4:10. doi:10.1147/JRD.2009.5388585.
 ^ z/Architecture Principles of Operation
 ^ ^{a} ^{b} "The Record Layout of a Data Set in SAS Transport (XPORT) Format" (PDF). Retrieved September 18, 2014.
 ^ "SEG Y rev 1 Data Exchange format, Release 1.0" (PDF). May 2002.
 ^ "Package 'SASxport'" (PDF). March 10, 2020.
 ^ Amdahl, Gene; Blaauw, Gerrit; Brooks, Jr, Frederick. "Architecture of the IBM System/360". IBM Journal of Research and Development. 1964: 87. Retrieved 4 September 2023.
 ^ Blaauw, Gerrit A.; Brooks, Frederick P. (1997). Computer Architecture (1st ed.). Reading, Massachusetts: AddisonWeslet. ISBN 0201105578.
Further reading[edit]
 Sweeney, D. W. (1965). "An analysis of floatingpoint addition". IBM Systems Journal. 4 (1): 31–42. doi:10.1147/sj.41.0031.
 Tomayko, J. (Summer 1995). "System 360 FloatingPoint Problems". IEEE Annals of the History of Computing. 17 (2): 62–63. doi:10.1109/MAHC.1995.10006. ISSN 10586180.
 Harding, L. J. (1966), "Idiosyncrasies of System/360 FloatingPoint", Proceedings of SHARE 27, August 8–12, 1966, Presented at SHARE XXVII, Toronto, Canada doi:10.5281/zenodo.10566524.
 Harding, L. J. (1966), "Modifications of System/360 FloatingPoint", Proceedings of SHARE 27, August 812, 1966, Presented at SHARE XXVII, Toronto, Canada doi:10.5281/zenodo.10566780.
 Harding, L. J. (1966), "Proposed Modification Of FloatingPoint Multiplication", proposed Engineering Change to IBM Corporation, doi:10.5281/zenodo.10567044.
 Anderson, Stanley F.; Earle, John G.; Goldschmidt, Robert Elliott; Powers, Don M. (January 1967). "The IBM System/360 Model 91: FloatingPoint Execution Unit". IBM Journal of Research and Development. 11 (1): 34–53. doi:10.1147/rd.111.0034.
 Padegs, A. (1968). "Structural aspects of the System/360 Model 85, III: Extensions to floatingpoint architecture". IBM Systems Journal. 7 (1): 22–29. doi:10.1147/sj.71.0022.
 Schwarz, E. M.; Sigal, L.; McPherson, T. J. (July 1997). "CMOS floatingpoint unit for the S/390 Parallel Enterprise Server G4". IBM Journal of Research and Development. 41 (4.5): 475–488. doi:10.1147/rd.414.0475.