RFA; DFP and REAL_TYPE?
So I've been looking at using REAL_TYPE to represent decimal floating point values internally (to implement the C extensions for decimal floating point.) I believe David and yourself had some discussions on this some short time back. Anyway, I've now had a chance to play with this a bit, but not quite sure how well I like the way its coming out (though the alternative of introducing new type seems worse, imo). Warning: My thinking is likely clouded by a goal to wire in the decNumber routines to implement the algorithms/encodings for decimal floats (still working through permissions for this to happen though). First, I think we need to avoid going into the GCC REAL internal binary float representation for decimal floats. I'm guessing going into the binary representation (then performing various arithmetic operations) and then eventually dropping back out to decimal float will end up with errors that are trying to be avoided by decimal float in the first place. I'm looking for advice to going forward. I've already hacked up real_value.sig to hold a decimal128 encoded value. This is fugly, and obviously all sorts of things in real.c would break if I started using the various functions for real. But before I put down any significant work down the REAL_TYPE path, I thought it best to get guidance. 1) Stick with REAL_TYPE or is it hopeless and I should create DFLOAT_TYPE? 2) If the recommendation is to stick with REAL_TYPE. Is it ok to have some other internal representation? 3) Is there a preferred way to override real_value functions? I'm assuming that even if I use the real_value->sig field to hold the coeefficient rather than the ugly hack of holding a decimal128, I'll need to override various functions in real.c to 'do the right thing' for radix 10 reals. I could add a field to real_value to point to a function table, that if present to be called through. Or simply add various "if (r->b == 10) checks throughout real.c. Or other. Thoughts/concerns/questions/advice? Best Regards, Jon Grimm IBM Linux Technology Center.
Re: RFA; DFP and REAL_TYPE?
Mark Mitchell wrote: 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]>
Re: libstdc++ link failures on ppc64
Diego Novillo wrote: I see no changes in libstdc++ since the previous run and nothing in the C++ FE, so I'm not sure whether it may be something broken in my box. Anybody else seeing this failure? Yep. I see this here on the PPC64 nightly autotester. Br, Jon
