First --with-long-double, then _Decimal64!

[Jeffrey Streifling <jss bulk gmail com>]

How many pieces have to be in place to make a --with-Decimal64 option
that works similarly to --with-long-double in configure?  That is, what
all does building with long-doubles affect, and what do they depend on?

A spreadsheet that used decimal floating point semantics would be quite
a handy thing for anybody who has thought that it might be nice to add
quantities of money, time, etc, in a spreadsheet.  (Using binary
floating point for this purpose must be considered a hack that goes back
to Visicalc!)

The basic infrastructure of gnumeric has already been parameterized to
accomodate --with-long-double, so in principle, it should be possible to
accomodate _Decimal64 as just another type using the same typedef and
#define tricks.

Intel has cooked up some fast routines for doing basic calculations with
decimal numbers based on IEEE 754-2008 and added them to gcc upstream,
so gcc supports the types and can do the basic math.  They're already
working on transcendentals (see John Harrison's paper, "Decimal
Transcendentals via Binary").

Some platforms like HP-UX already have decimal support in their libc,
but John Harrison's paper shows that in many cases, if you have 80 bit
long doubles, you can just cast your _Decimal64 to long double and pass
it to the existing long double libc function to get accurate results, at
least for transcendentals.  (This is suggested as a quick hack to get
things working until C libraries are properly updated.)

Doing conversions to and from _Decimal64 via C library long double
functions would partly defeat the purpose of the exercise, but doing
custom conversions between external representations and _Decimal64 is
straightforward compared to the contortions required to convert to and
from binary floating point, and in any case, doing custom conversions
would be worthwhile because they could preserve trailing zeros. 
(Decimal floating point is not normalized like binary floating point
is.)  Bitfields from _Decimal64s could be manipulated as 64 bit long
longs and converted to digit strings with existing C library integer
functions for formatting.

Somebody will ask, "What about _Decimal128?"  Well, it would be nice,
but _Decimal64 is a nice place to start, especially considering that
performance better, transcendentals might get calculated with long
doubles until C libraries are updated, and it is a bit tricker to
manipulate bitfields from _Decimal128s since they can be longer than 64
bits, the longest integers in available in typical C environments.

Getting Gnumeric to work with _Decimal64s would make a lot of things
work "right" like accurate representations of decimals that have an
internal idea of significance instead of relying on various rounding
tricks to fit prefabricated formats.  In addition to the
representational accuracy issue, a spreadsheet using decimal arithmetic
would reduce the required effort for formatting each number to round to
a suitable number of decimal places since most numbers would already
have an internal idea of what sort of external representation would be
sensible.  In some sense, it should have always been that way, but only
recently have the tools to make it work practically been coming together.

Jeffrey Streifling