Re: [cc65] IEEE vs nonstandard floats

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-03-10 00:09:42


Hi!

On Sun, Mar 09, 2003 at 01:46:07PM -0800, David Holz wrote:
> What would cc65 gain by having IEEE standard FP notation as opposed to a
> custom one that ran faster on the 6502?

If you can prove in advance that a specific custom format is significantly
faster than the IEEE format, I'm open for this suggestion. But I have to admit
that I doubt this is the case.

A floating point number consists of two parts: Mantissa and exponent. The
existing formats (yes, also the one used by Commodore) differ only in the
representation of these two parts in the binary representation of the floating
point number. The floating point routines need to work on both parts
separately, so most of the difference is in separating the two components and
joining them after the computation part is done.

Maybe you can tell which concrete properties of the IEEE 32 bit format will
lead to a slow implementation, so we can discuss the possible impact and
alternatives.

> The only one that I could think of
> would be read/write compatibility with files that export floating point in
> binary files which isn't that common.

Here's another one: The standard specifies explicitly how the different
situations should be handled, so it is easy to diagnose if there are problems
with the implementation, and a user knows exactly what he can expect.

> NaN and infinite also don't show up in Posix C programs without tossing a
> SIGFPE signal do they?  If not, they don't need to be handled with special
> code which can tighten up the FP library and make it easier to implement.

The C standard does not require fp math functions to raise a signal on an
error condition. But it requires that the a math function returns an
implementation defined value, so these error conditions have to be detected
and handled in some way. I don't think that raising a signal is a good idea
(my comment suggesting this was a joke) but the few bytes saved by not calling
raise() are definitely not the reason for it.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-03-10 00:10:44 CET