RFC on floating point output work

[Jerry Quinn]

Paolo Carlini writes:
 > Benjamin Kosnik wrote:
 > 
 > >Jerry,
 > >
 > >Paolo had told me in passing that he knows of another intrepid hacker
 > >who is interested in working on this. The details escape me at the
 > >moment, sorry. Perhaps he can provide more information and an
 > >introduction for you, so that a team effort can be applied to this problem?
 > >
 > :)
 > 
 > >Paolo?
 > >
 > Yes, I contacted Jerry back in July and discussed a bit the various 
 > options (i.e., snprintfv by Paolo Bonzini). Then Jerry proceeded alone a 
 > long way and now I see that he has something already quite defined.

Yes, I looked at snprintfv for a while.  The big problem I saw was
that it was trying to do all the math in long double.  The first
problem here is that gcc 3.4 seems to have trouble with long double
calculations, and the other concern is that at least for printing of
long doubles, you need even more precision to get it right.  I think
that's why the glibc and old libio (floatconv) approaches used bigint
representations.

 > 
 > I'm planning to study deeply his current floatconv.cc in the next few 
 > days and report.
 > 
 > Jerry, which kind of speed improvements do you expect for the final 
 > result (including localization)?

Floatconv has optimizations to use native doubles when the requested
precision allows.  In those cases, output will be really fast, since I
didn't see any optimizations like that while perusing the glibc code.

When floatconv has to fall back to bigint representation, it will be
in the ballpark of glibc, but maybe not as fast since it uses a
portable C implementation of bigints.  Glibc uses an old version of
gmp, which already has cpu-specific optimizations including assembly
routines.  The current version of gmp is probably even faster,
although it may not matter for the types of operations used in
floating point conversions.

I also expect to pick up a bit of speed since we'll avoid the overhead
of printf string parsing.  However, the only speed comparisons I've
done so far are some simple tests.  They do show that floatconv is
MUCH faster than printf or snprintfv for relatively small doubles, and
~10% slower than glibc for large doubles that end up in bigints.

Going forward, the places I will really need the most help are:

1) Portable identification of 32 bit int types

2) Evaluation and configuring of several features:

Unsigned_Shifts	- does >> treat the left op as unsigned?
	Is this no longer relevant?
FLT_ROUNDS - can FLT_ROUNDS be 2 or 3?

3) Evaluate VAX and IBM code

I'm not a floating point expert and don't have any way to evaluate
those code paths.

4) Identify other float formats we need to deal with

5) Suggestions for the best way to proceed on handling long double

As I mentioned above, it seems that long double doesn't actually
work.  Hence my plan is to simply see if a long double can be
represented as a normal double and print out if possible, otherwise
convert it to a bigint.

The issue from a config standpoint I see is that I think x86 uses 96
bit ieee extended for long double.  I expect some platforms use 128
bit quads.  I assume in both cases we want to use the same codepath.

Thanks,
Jerry