Re: [cc65] Floating point support?

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.

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

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

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.

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

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

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.