A Decimal Floating-Point Speciftcation

A Decimal Floating-point Specification Michael F. Cowlishaw, Eric M. Schwarz, Ronald M. Smith, Charles F. Webb IBM UK IBM Server Division P.O. Box 31, Birmingham Rd. 2455 South Rd., MS:P310 Warwick CV34 5JL. UK Poughkeepsie, NY 12601 USA [email protected] [email protected] Abstract ing is required. In the fixed point formats, rounding must be explicitly applied in software rather than be- Even though decimal arithmetic is pervasive in fi- ing provided by the hardware. To address these and nancial and commercial transactions, computers are other limitations, we propose implementing a decimal stdl implementing almost all arithmetic calculations floating-point format. But what should this format be? using binary arithmetic. As chip real estate becomes This paper discusses the issues of defining a decimal cheaper it is becoming likely that more computer man- floating-point format. ufacturers will provide processors with decimal arith- First, we consider the goals of the specification. It metic engines. Programming languages and databases must be compliant with standards already in place. are expanding the decimal data types available whale One standard we consider is the ANSI X3.274-1996 there has been little change in the base hardware. As (Programming Language REXX) [l]. This standard a result, each language and application is defining a contains a definition of an integrated floating-point and different arithmetic and few have considered the efi- integer decimal arithmetic which avoids the need for ciency of hardware implementations when setting re- two distinct data types and representations. The other quirements. relevant standard is the ANSI/IEEE 854-1987 (Radix- In this paper, we propose a decimal format which Independent Floating-point Arithmetic) [a]. The IEEE meets the requirements of existing standards for deci- 754 standard [3] is a binary standard which also mal arithmetic and as eficient for hardware implemen- meets this radix-independent standard. The radix- tation. We propose this specification in the hope that independent standard gives us guidelines for formats designers will consider providing decimal arithmetic in and exponent ranges that need to be considered and future microprocessors and that future decimal software specifically describes requirements for base 10 floating specifications will consider hardware efficiencies. point. A floating-point format must also permit efficient implementation. One of the difficulties with decimal 1. Introduction arithmetic is that it is less efficient than binary arithmetic. Representations take up more memory and exe- People habitually perform arithmetic in base 10. cution time of an operation is inherently longer. How- When calculations are moved to computers there is ever, if the data is already stored in memory in a dec- usually a loss in translating decimal fractions to a imal format and conversions between decimal and bi- binary representation. Common decimal values such nary formats are costly, then it can be more efficient as 0.1 can be represented exactly in decimal but can to carry out computations directly in decimal. Fur- only be approximated in a binary floating-point for- ther, if the chosen format requires very little hardware mat. Traditionally, financial transactions are therefore to support then it is likely that future microproces- performed in a scaled binary or decimal integer for- sors would implement it in hardware, just as most im- mat. Both of these formats are fixed point and so, plement binary floating-point arithmetic today. From even though they avoid fraction approximation, they a financial and business software standpoint, decimal are severely limited in the range of numbers they can floating-point hardware is as attractive as a graphics represent. Further, in many applications, such as the engine is attractive to a games developer. calculation of a monthly mortgage payment, round- Other considerations in developing a specification 147 0-769s-I 150-3/01 $10.00 0 2001 IEEE Language Platform Support Precision Comments c & c++ S/390 Fixed 31 C only AS1400 Fixed 31 C only Others Fixed 31-38 In various libraries COBOL All Fixed 31 32 digit Floating proposed C# All Float 28 Java All Floating infinite Using IBM BigDecimal class; java.math is fixed point os/400 CL AS/4000 Fixed 15 Scale <= 9 PL/I S/390 Fixed 15 The FLOAT Decimal data type is actually binary AS1400 Fixed 15 Others Fixed 31 PSM All Fixed 31 Implemented via translation to C Rexx All Floating infinite RPG AS1400 Fixed 30 Scale <= 9 Table 1. Software and Platforms Implementing Decimal Arithmetic are that it should be efficient for reading and storing The remainder of this paper discusses a specifica- decimal data in databases. Decimal data are usually tion for decimal floating-point data types which best stored in Binary Coded Decimal (BCD) notation. Typ- meets these goals and fits within appropriate lengths. ical decimal data are fixed point with up to 20 dig- Existing hardware architectures suggest that represen- its of precision, including up to 10 fractional digits. tations be 32, 64,80, or 128 bits in length, and these are There needs to be efficiency in reading the data out convenient for software, too. It is proposed that only of a database, operating on it, scaling and rounding 64 and 128 bit representations be defined at this time, it, and then storing the data back into the database forming the single and double formats as described in with a fixed point notation. These requirements favor the IEEE 854 standard. Some prior work by Johnstone a BCD format. and Petry [4] showed a 32 bit format but this length A further constraint on a specification is the need to does not meet most software requirements. Hull [5] allow for future expansion of the notation. An architec- suggests a variable precision format but this does not ture or format should be robust enough to grow with map easily to hardware implementations. Note that future changing needs. One possible mechanism could the 854 standard requires a single precision be defined be through the use of special values. There needs to be and recommends that there should be an extended pre- enough room in the format to support infinities, Not-a- cision. Double precision satisfies the requirements of Number (NaN) values, and both positive and negative single-extended precision. zeros. In the future there might be additional values, Software requirements are first discussed, followed such as subnormal numbers, considered too. by the overall decimal format, which is similar to that In summary, the goals of the specification are: described by Ris[G]. These are followed by discussion on the efficiency and requirements for each part of the 1. It should allow efficient hardware or software im- format, including the representation of the integer, ex- plementation of decimal floating-point ponent, and special values, the ordering of parts, and 2. It should support numbers to be used for the the length of the exponents. Finally, complete formats floating-point and integer decimal arithmetic de- will be described. fined in ANSI X3.274-1996 (Programming Lan- guage REXX) 2. Software Requirements 3. It should support numbers and values to be used for the floating-point arithmetic defined Table 1 shows a list of several common languages in ANSI/IEEE 854-1987 (Radix-Independent which define decimal arithmetic (sometimes using li- Floating-point Arithmetic) braries). Also listed is the support that is provided on 4. It should allow efficient use of existing data in a given platform. The IBM S/390 (2-Series) platform databases has 31 digit decimal integer arithmetic hardware and this is used by many of the languages including C and 5. It should allow for future expansion. COBOL. Java and REXX both provide floating-point 148 decimal representation with an unlimited number of the data in memory, which are typically in BCD for- digits. For other languages, the required support is ap- mat, or it could be a more compact format. If it is proximately 31 or 32 decimal digits. There are some more compact then a transformation step is required instances of 38 digit support in both languages and to move data from memory into the internal format. databases. Hence, the maximum requirement in prac- Other effects that are important are that overflows or tice appears to be 38 digits, although 31 or 32 digits rounding precision boundaries are more easily spotted meets the needs of almost all real applications. if the format allows easy identification of decimal digit boundaries. Similarly, carries can easily be detected 3. Decimal Arithmetic Specification and renormalization of the representation is made eas- ier if decimal digit boundaries are preserved. On the other hand, decimal adders are slightly slower than bi- There has already been work in defining a standard nary adders and more complex operations are corre- decimal floating-point arithmetic specification [7, 81. spondingly slower, too. Therefore, the integer format These documents define a set of operations and rules, must be picked carefully. but do not define a concrete representation of numbers. The three most interesting formats for the integer The present study discusses the choice of representa- are: 1) Binary format , 2) Binary Coded Decimal for- tion. mat (BCD, 4 bits per digit), 3) Compressed BCD for- These other decimal arithmetic specifications [7, 81, mat. however, detail many useful aspects such as the oper- Binary representation is the most compact form and ations, formats, and rounding modes that need to be allows very fast multiplications and divisions. In this supported to be useful for multiple languages and ap- format, additions and subtractions which require shift- plications. The core operations needed are Add, Sub- ing are slow, and rounding and normalization can be tract, Plus, Minus, Multiply, Divide, Power, Divide- difficult.

Load more