Re: [cc65] Floating point support?

On 26 Sep 2004, at 22:01, Ullrich von Bassewitz wrote:

> On Sun, Sep 26, 2004 at 01:02:07PM +0200, Sidney Cadot wrote:
>> Just out of curiosity... Have you given any thought on adding floating
>> point support to cc65?
>
> Lots of course, and there's even some code in the development 
> compiler:-) Most
> of my thoughts led into the same direction as what you wrote. My plan 
> was to
> use the IEEE 32 bit format (I think this has been discussed in the 
> list some
> time ago). I learned only recently that the IEEE 32 bit format does 
> not meet
> the ISO C requirements for the data type double. Since implementing 64 
> bit
> floats on the 6502 is out of question, there are two remaining 
> approaches:
>
>   * Use another, maybe non standard format. As far as I remember, 5 
> bytes (40
>     bits) should be enough for a standard conforming double data type.

 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.

>   * Use the 32 bit data format and accept that the compiler won't be
>     conforming in this respect.
>
> There is a lot that speaks for the latter approach:
>
>   * Since 32 bits are already used for longs, the routines to 
> load/store or
>     move data are already there. Adding the same for a new data type 
> would
>     increase code size.
>
>   * 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 ;-))

An OS-independent implementation of floating-point routines seems a bit 
cleaner to me.

> But as you know, I'm rather serious about standards, so I'm not really 
> happy
> with it.

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.

> Major problems are the compiler and assembler. The expression 
> evaluation in
> the assembler does only work with integers, and does currently not 
> support any
> types. Adding floats would also mean that the expression evaluation 
> has to be
> rewritten to support types. This includes the expression trees passed 
> to the
> linker. As a consequence, the linker must know how to handle floats. 
> For a
> first solution, this can be ignored if the compiler translates 
> floating point
> data into .byte statements. But the compiler is the next problem: 
> There are
> parts of the compiler (code generation) that are strictly integer 
> based and do
> not cope easily with a new data type. So these parts have to be 
> rewritten
> before a new type can be added. But ... quite a lot of other changes 
> have
> already been started. I would really like to finish those before adding
> floats.
>
> In other words: While I'm thinking about floats, and about to slowly 
> add code
> to support them, it's definitely not top priority.

Sure, anyway I'm glad you're thinking about it, and that some efforts 
are being made for it.

>> Now if such a roadmap (or similar) would be acceptable, I would
>> volunteer to take care of steps (2) and (3).
>
> We can talk about the road map, and find a solution for the floating 
> point
> format, but step 4 (changes of the compiler, assembler and linker) will
> definitely not happen in the near future. If that is ok for you, I 
> would
> happily accept a contribution. Maybe the functions can be used from 
> assembler,
> or I can at least add the ability to store floats to the compiler, so 
> while
> floats cannot be processed, they could be moved around and passed to 
> assembler
> functions.

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.

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. If 
that's ok, I'll start working on this; however I have a busy job so 
even the implementation of these basic functions will likely take a few 
months on the calendar.

> Calling conventions will be as with integer stuff: First argument is 
> on the
> stack, second argument is in a register.

Ok.

Regards, Sidney

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.