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.
