Robert Dewar wrote:
Mark Mitchell wrote:
I would expect that some decimal floating point values are not precisely representable in the binary format.
OK, I agree that decimal floating-point needs its own format. But still you can store the decimal mantissa and decimal exponent in binary format without any problem, and that's probably what you want to do on a machine that does not have native decimal format support.
I would think that, as elsewhere in real.c, you would probably want to use the same exact bit representation that will be used on the target. This is useful so that you can easily emit assembly literals by simply printing the bytes in hex, for example.
Of course, you could do as you suggest (storing the various fields of the decimal number in binary formats), and, yes, on many host machines that would in more efficient internal computations. But, I'm not confident that the savings you would get out of that would outweigh the appeal of having bit-for-bit consistency between the host and target.
In full disclosure, the 754r encoding is pretty ugly: high order bits from exponent and coefficient are packed into one field. The remaining bits of the exponent are in a second field, and the remaining bits of the coeffecient are compressed decimal encodings. So you pretty much have to come out of that encoding to do much useful with it.
Honestly, I've been most just used the real decimal128 encoding as it was easiest to integrate with decNumber. decNumber has yet another architecture neutral format it does its computations in, but that didn't fit in the real_type, so I just used decimal128 as it 'fit' and decNumber could internally deal with that format already.
In any case, this is rather a detail; the key decision Jon is trying to make is whether or not he has to introduce a new format in real.c, together with new routines to perform oeprations on that format, to which I think we agree the answer is in the affirmative.
Yes. Thanks! This is exactly the discussion I was interested in (and to validate that my thinking was not totally off kilter). The specific internal representation can change once real.c is safe for some different representation.
-- Jon Grimm <[EMAIL PROTECTED]>
