Decimal Arithmetic FAQ
Part 3 – Hardware Questions 
Most computer architectures other than ‘pure RISC’ machines do, in fact, provide some form of decimal arithmetic instructions or support. These include the Intel x86 architecture (used in PCs), the Motorola 68x architecture and its derivatives (used in Apple’s earlier machines and the Palm Pilot), the IBM System z (the descendents of the IBM/360 family), the HP PARISC architecture, and most generalpurpose microprocessors.
However, for all of these machines, only integer decimal arithmetic is supported, and for most the support is limited to decimal adjustment or conversion instructions which simplify decimal operations. These instructions are only accessible through assemblylanguage programming, and lead to only small performance improvements. In all cases, any scaling, rounding, or exponent has to be handled explicitly by the applications or middleware programmer; a complex and very errorprone task.
The native (hardware) decimal floatingpoint arithmetic now available in the IBM Power6 processor and expected in the z6 microprocessor makes programming far simpler and more robust, and with much better performance than software (for details of the new hardware implementations, see the General Decimal Arithmetic page).
Many early computers (such as the ENIAC, or the IBM 650) were in fact decimal machines. In the 1950s, however, most computers turned to binary representations of numbers as this made useful reductions in the complexity of arithmetic units (for example, a binary adder requires about 15% less circuitry than a decimal adder). This reduction in turn led to greater reliability and lower costs.
Storing decimal integers in a simple binary coded decimal (BCD) form, rather than a pure binary form, also uses up to 20% more storage than the binary form, depending on the coding used.
Later, it was also shown that binary floatingpoint allows simpler error analysis, and for a given number of bits gives more accurate results for certain mathematical operations.
Decimal arithmetic, therefore, is inherently less efficient than binary arithmetic, and at the time this justified the switch to binary floatingpoint arithmetic (just as a twodigit representation for the year in a date was justifiable at the time). However, the programming and conversion overheads and other costs of using binary arithmetic suggest that hardware decimal arithmetic is now the more economical option for most applications.
No, it is not. The performance of existing software libraries for decimal arithmetic is very poor compared to hardware speeds. In some applications, the cost of decimal calculations can exceed even the costs of input and output and can form as much as 90% of the workload. See “The ‘telco’ benchmark” for an example and measurements on several implementations.
Binary floatingpoint emulation in software was unacceptable for many applications until hardware implementations became available; the same is true for decimal floatingpoint (or even fixedpoint) emulation today. Even using the decimal integer instructions on an IBM System z machine only improves fixedpoint performance by about a factor of 10; rounding and scaling in software adds significant overhead.
Complaints about the performance of decimal arithmetic are extremely common. Software emulation is 100 to 1000 times slower than a hardware implementation could be. For example, a JITcompiled 9digit BigDecimal division in Java^{TM} 1.4 takes over 13,000 clock cycles on an Intel Pentium. Even a simple 9digit decimal addition takes at least 1,100 clock cycles. In contrast, a native hardware decimal type could reduce this to a speed comparable to binary arithmetic (which is 41 cycles for integer division on the Pentium, or 3 for an addition).
The benefits are even larger for multiplications and divisions at the higher precisions often used in decimal arithmetic; a 31digit division can take 20–110 times as long as a 9digit addition.
Yes. The first microprocessorbased electronic calculator, the Busicom (actually a desktop machine), used its Intel 4004 to implement decimal arithmetic in 1970.
Later, the Hewlett Packard HP71B calculator used a 12digit internal decimal floatingpoint format (expanded to 15 digits for intermediate calculations), to implement the IEEE 854 standard.
Today, the Texas Instruments TI89 and similar calculators use a 14digit or 16digit Binary Coded Decimal internal floatingpoint format with a three digit exponent. HP calculators continue to use a 12digit decimal format; Casio calculators have a 15digit decimal internal format.
These all use software to implement the arithmetic, as singlecalculation performance is not usually an issue. Oddly, most calculators discard trailing fractional zeros.
Yes. IBM announced on 18 April 2007 hardware decimal floating point facilities for IBM z9 EC and z9 BC:
Base 10 arithmetic is used for most business and financial computation. To date, floating point computation used for work typically done in decimal arithmetic has involved frequent necessary data conversions and approximation to represent decimal numbers. This has made floating point arithmetic complex and error prone for programmers using it in applications where the data is typically decimal data.
Initial software support for hardware decimal floating point is limited to High Level Assembler support running in z/OS and z/OS.e on System z9. z/OS V1.9 will provide support for hardware decimal floating point instructions and decimal floating point data types in the C and C++ compilers as a programmerspecified option. Support is also provided in the C Run Time Library and the dbx debugger. This function is also supported by z/VM V5.2 and later for guest operating system use. There is no support available for machines earlier than System z9. Refer to the Software requirements section.”
Since then, IBM has also announced support for decimal floatingpoint in the Power6 processors, and has released details of the decimal floatingpoint unit in the z6 microprocessor. For details of these hardware implementations, see the General Decimal Arithmetic page.
Please send any comments or corrections to Mike Cowlishaw, mfc@speleotrove.com 
Copyright © IBM Corporation 2000, 2007. All rights reserved.
