RFC on floating point output work

[Jerry Quinn <jlquinn at optonline dot net>]

Hi, folks.  Over the last couple of months, while I wasn't sinking at
work, I've been playing with cleaning up the floating point printing
routines from the old libstdc++ to use in place of printf conversions.

I've taken the original file floatconv.c from gcc 2.95's libio and
done a number of changes to it, while leaving the algorithm alone.
The big visible changes are:

1) Wrappering a bunch of the bit twiddling done to doubles
There were a lot of constants and inline twiddling to extract
exponents and such.  I've tried to clean that up.  I think it's a big
improvement, although it is cosmetic.

2) Removed the static storage originally used in the conversion output
This involved breaking up the dtoa function into two parts.  The first
part, dec_exponent(), returns an estimate of the exponent of the
number.  This estimate is off by one at most and always is an upper
bound, so now we can allocate storage on the calling stack frame
reasonably.

3) Started trying to wrapper the bigint stuff

I didn't get too far with this yet.

4) Adding long double support

This is more of a black hole for me.  The main thing I'm not sure
about is how to handle extended double vs. quad.  Also how to handle
long double on machines such as VAX and IBM 390, the other fp types
handled by this code.

On the face of it, things shouldn't be too bad.  If the long double is
small enough to be put into a double, we can use the routines as is.
Otherwise, we use only the bigint part of the code (there are
optimizations for small enough doubles).

5) Creating the conversion routines

This is complete as far as a standalone program goes.  There's still
work to do to integrate it into the library.

What I have now works well.  I've run 500,000 random doubles (random
bit patterns) and compared the output to printf on glibc 2.3.1 with
excellent results on gnu/linux x86.  The only differences at this
point are ones that appear to me to be bugs in glibc, according to the
printf manpages.


Anyway, at this point I'd like to get some other opinions before I
plow ahead too much further.  I've gone this route because this code
is very fast for some doubles, and otherwise about the same
performance as glibc.  I looked at using the core routines in glibc,
but that involved extracting a complete version of the gmp library.
Out of date at that.  Also, using the glibc stuff might mean jumping
through some hoops to straighten out licensing.

The disadvantage to the current code is it uses a portable
implementation of big integer math versus gmp which has
platform-specific optimizations.  Glibc's version has some
optimizations as well.

You can look at my work in progress

http://bakerquinn.homelinux.net:8081/floatconv.cc

At the moment it is a standalone c++ program that will blast random
doubles through the conversion and compare the results to printf.

Thanks for any comments,
Jerry Quinn