FP Conversions

[Earl Killian]

Everyone agrees accurate conversions are desirable, but those against
requiring them suggest they're too expensive.  Everything is highly
subjective.  Let's get some hard data.  Let me begin:

MIPS has been shipping accurate fp <-> decimal conversion routines for
a couple of years now.  They took about 2 weeks time for one
programmer to write and debug in assembler.

The number of lines of code is small, in my opinion:

     177     667    3197 atod.s
     117     369    2063 atof.c
     243     862    4060 dtoa.s
      50     328    1606 dwmultu.s
      43     179    1111 ecvt.c
     236     908    5260 tenscale.s	(mostly a lookup table)

as is the code size:

	text    data    bss     dec     hex
	544     16      0       560     230     atod.o
	544     16      0       560     230     atof.o
	768     16      0       784     310     dtoa.o
	128     0       0       128     80      dwmultu.o
	400     0       96      496     1f0     ecvt.o
	336     688     0       1024    400     tenscale.o

These routines, which are accurate over the full range, take 860 cycles
to do
	ecvt (value, 17, &decpt, &sign);
and 903 to do
	atof (s);
(where s is 17 digits with a 3 digit exponent).  All values generated
with a 64-bit random number generator, and so these are averages of
most of the different paths through the code.

They are implemented using 64-bit integer arithmetic.  About half the
time in the atof call is parsing, and not conversion.  The ecvt time
is mostly conversion.

I don't know if that's slow or fast by other people's standards, but
it seems acceptable to us.

I suggest others post their conversion times and we'll separate them
into accurate and not-accurate and see if there is a significant
difference.