Re: [cc65] floating point support redux

From: Kevin Schuetz <scrapdog1runbox.com>
Date: 2010-04-08 22:19:11
Thanks for replying!

Ullrich von Bassewitz wrote:

 >
 > And, having two implementations makes it easier to find problems,
 > because you can check the results against each other.
 >

Good point!

 >
 > The real work is getting support into the compiler, and
 > writing all the library extensions for the 6502 (think about printf ...).
 >

Trust me, I have (at the expense of some sleep)!  printf is a mountain 
of a function. :-)


 >
 > A standards compliant double needs 34 bits in the mantissa (10 digits of
 > precision), so it needs 64 bit IEEE floats or some non standard format.
 >

Is performance and space economy the main argument against 64-bit 
doubles, or is there something else?

As soon as a programmer knowingly makes a decision to use a double 
instead of a float on a 6502, they probably have pondered the 
consequences.  If one knows the consequences yet proceeds to do it 
anyway, it is probably safe to say that performance *really* takes a 
back seat to precision on the particular problem they are tackling.

A 40-bit or 48-bit double might be a good compromise for performance, 
but is it really worth the trouble of designing and documenting a 
non-standard format, knowing how rarely it'll be used?

While a custom-tailored format (e.g. byte-aligned exponent, etc.) might 
ease some of the implementation troubles, any format is going to be 
painful to implement, isn't it?  Dropping the design and documentation 
burden might reduce the net amount of insanity. ;-)

In summary, I like the idea of 32-bit floats and 64-bit doubles.

That said, down the road if the floating point project materializes, I'd 
be willing to help out...

Kevin

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Thu Apr 8 22:19:22 2010

This archive was generated by hypermail 2.1.8 : 2010-04-08 22:19:24 CEST