[discuss] Re: RFC: Support IEEE 754R draft in the x86-64 psABI

Raul Miller moth at magenta.com
Wed May 10 20:02:36 CEST 2006


On Mon, May 08, 2006 at 07:34:22PM +0100, Mike Cowlishaw wrote:
> http://www2.hursley.ibm.com/decimal/DPDecimal.html

The encodings suggested in this document seem to 
be needlessly complicated

For example, consider the example table:

BCD  	Chen-Ho  	Densely Packed
005 	000 000 0101 	000 000 0101
009 	110 000 0000 	000 000 1001
055 	000 010 1101 	000 101 0101
099 	111 000 1001 	000 101 1111
555 	010 110 1101 	101 101 0101
999 	111 111 1001 	001 111 1111

Simple binary representation achieves the same packing density,
005     000 000 0101
009     000 000 1001
055     000 011 0111
099     000 110 0011
555     100 010 1011
999     111 110 0111

Once again, I do not see that "efficient support for existing BCD formats"
justifies a system which is harder to describe, and harder to support
in software.  For example, consider the issues associated with converting
pure binary numbers to and from these formats.

A primary issue, for formats used in long-term storage, should be
simplicity of the format itself.

Saving a few gate delays in some specialized implementation where no
bottleneck has been demonstrated does not seem to justify creating
a storage format where a human would need to either memorize a large
lookup table to read a number from its representaiton in a static display
or printout.

Existing floating point formats are readable, and complexity issues
which impact software (such as denormalized numbers, near zero) have
justifications which are easy to understand.

I would like to ask that if the above complexities are justified that
someone point out a simple and complete explanation of this justification.

Put differently: "...97% of the time: Premature optimization is the root
of all evil."

Thanks,

-- 
Raul



More information about the discuss mailing list