Re: [cc65] Floating point support?

On Sun, Sep 26, 2004 at 11:27:12PM +0200, Sidney Cadot wrote:
> From the C99 spec, section 5.2.4.2.2, the relevant limit is DBL_DIG
> that in essence requires at least 10 decimal digits to be representable
> accurately. Since log(10^10)/log(2) equals 33.2193, one would need at
> least 34 bits of mantissa to fulfill the requirement. The
> DBL_MIN/DBL_MAX requirements essentially state that you need at least
> an 8-bit exponent, and we still need a mantissa sign bit - the minimum
> number of bits required would be 43 in total I think - so at least a
> six-byte double would be needed.

Ok.

> >  * The compiler could require that the float data type of the source
> >platform
> >    is the 32 bit IEEE float type (this is true for all hardware cc65
> >does
> >    currently run on). This would mean that no special floating point
> >routines
> >    would have to be written for the compiler itself.
>
> This is not true for the Atari, which uses a rather awkward 6-byte
> BCD-based format,  (and also for the FPGA-based 6502 that I recently
> implemented - on which cc65 works like a charm, by the way ;-))

I was talking about the *compiler*, not one of the targets. The compiler must
be able to evaluate floating point expressions in exactly the same format as
the target platform, otherwise expressions evaluated by the compiler would
have other results than the ones evaluated by a program running on the target.
If we agree on a non standard 6 byte floating point format, there must be a
full floating point implementation for this format in the compiler (and maybe,
assembler and linker). If we agree on one of the standard formats, the
compiler can use what is already there. As a consequence, the compiler would
only run on machines using IEEE floating point, but today that's not a real
limitation.

> Yes, and rightly so. Still, it would perhaps be a good idea to add
> supports for 4-byte floats first, then based on the experience look
> towards a 6 (or even 8) byte double.

That's not really an option, because it means doing most of the work twice.

> That's fine. As a starting point, I think it would be convenient if at
> least the basic operations were available (addition, subtraction,
> multiplication, division, and comparison operators - am I missing any
> out?), this would at least allow people to do basic FP stuff using
> function calls for now, and these will suffice later on for providing
> compilation ability.

Yes, but as I said already: Not in the near future. What you call "basic
operations" requires most of the real work to be done.

> I propose to settle on IEEE-754 single-precision for now. We should be
> able to use these as a base for a widened implementation later on.

I don't agree with the latter. As I said above, changing horses is not really
an option, because it means doing most of the work twice. So, *if* we agree on
the 32 bit IEEE format, we will have to do that knowing that it will be the
only format, and that it doesn't meet the requirements of the C standard,
meaning that some code requiring more precision (which is guaranteed by the
standard for a conforming implementation) will not to run. Please note that I
don't vote against the 32 bit format. I just want to show the consequences of
the decision. Maybe we should consider a 6 byte format, just to see what that
would mean. The data type REAL implemented by Turbo Pascal was a 6 byte data
type, and it was quite fast. But then, the platforms where it was implemented
had 16 bit registers ...

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.