Re: [cc65] floating point support redux

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2010-04-09 22:10:27
Hi!

On Thu, Apr 08, 2010 at 03:19:11PM -0500, Kevin Schuetz wrote:
> Is performance and space economy the main argument against 64-bit
> doubles, or is there something else?

Yes. As Groepaz already said, 64 bit floating point is so slow on the 6502
that is't more or less useless for all practical purposes. 

The beauty of the 32 bit floating point format is that it can reuse the
existing 32 bit routines not only for movement (push/pop/load/store/...), but
also for the arithmetic routines. The 32x32 multiplication and division
routines can be used for operations on the mantissa, saving quite some space.
The 64 bit format has a 48 bit mantissa, so we need additional routines to
handle it.

> 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.

Not really. The problem is the default argument promotion. The C standard
defines that in a variable argument list (or in absence of a prototype),
floats are promoted to doubles. So functions like printf never see floats,
they always get doubles. Even if a programmer takes great care to avoid the
use of doubles, a simple call to printf will cause the whole 64 bit floating
point library to get linked in, even if only floats are passed.

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

Thanks!

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Apr 9 22:10:34 2010

This archive was generated by hypermail 2.1.8 : 2010-04-09 22:10:36 CEST