floating point support is missing

[cc65]

floating point support is missing

[mrdudz]

That we want integral datatypes to work as the standard dictates is simply not up for discussion.

[aquishix]

Greetings.

I am almost certainly going to be the person to hand over the 6502 assembly implementation for floating point support in cc65. Does anyone know whom to talk to? I need to ask some questions and coordinate some things in order to proceed, and I am keenly interested in contributing.

I've already done most of the implementation work(from scratch, by hand) because I'm using it in my own company's NES game development, so these are not idle claims. ;)

Instead of responding here on github, email me at:

jared a t somethingnerdystudios d o t com

[mrdudz]

I have in the meantime updated and fixed and tested my little library, btw - so it can be used, if you really wanted.

[mrdudz]

Well, to me it sounds like a specific division algorithm being present shouldnt be what is stopping this.

This change should be split into two different things anyway, compiler support, and then a floating point library that provides the fp primitives. The library can then be improved later (and it should be possible to replace it entirely, eg by one that uses the ROM of the target computer). I wouldn't be too worried about execution speed either, floats will be borderline slow. As with most other things in the library, size is likely a more important resource, so (large) LUTs arent really what we want either.

In any case, a PR that adds those things would be a good start :)

[aquishix]

Right. The LUT we're talking about is a 2KiB one, which is pretty minimal in our opinion but might be considered large by others. That was also part of why I didn't want to submit our code yet. Also, the particular format chosen was binary16 from IEEE 754-2008, which is really not that bad on a 6502 based computer. Additions can be performed in only a few hundred cycles, and multiplications often can as well when subnormals are not involved. (I supported subnormality in both addition/subtraction and multiplication.) I disagree with the C standard on what should count as "single" and "double" precision. It makes absolutely no sense to me to allow "int" to be either 2 bytes or something even stranger, but "single" and "double" are stuck at being absurdly high precision without violating the standard. That's another thing that I'd want to have the community agree upon before submitting this. In my opinion, cc65 should have "single" be 16 bit and "double" be 32 bit. This is the only compromise that makes sense given the typical clock speed of a 6502 based machine. It's not like cc65 is a true C compiler anyway. Even if it were, everyone is told not to use a lot of the features in order to avoid destroying performance. So I think the obsession about strictly adhering to the C standard's data type specifications ought to end and reasonable compromises be made that favor performance over adherence to the standard. C was invented for the PDP-11 which is a 16-bit computer with 8 general purpose registers. C was a reasonable fit for x86 because even the 8086 itself has four 16-bit registers with varying purposes. By contrast, the 6502 has one 8-bit accumulator and two 8-bit index registers. The accumulator can't be INCed or DECed and non-INC non-DEC arithmetic can't be conducted on the X or Y registers. All of this is why it was so hard to get subnormality working correctly without resorting to wasting space for extra bit width in the floating point data structure -- which is what Microsoft resorted to when writing support for floating point data types in BASIC for the Commodore 64 and other 8-bit microcomputers in the 1980s. So if I had my way, I would initially enhance cc65 to have "single" and "double" both pointed to 16-bit data types and then "double" enhanced later to 32-bit. If the maintainers to cc65 will agree to this, we will submit our code. It has already been optimized and proven to be correct for addition, subtraction, and multiplication. However, we have not implemented the various rounding modes because they have no practical use for our project and I feel like they're arguably yet another misguided part of the standard. It's going to be rough at first and in the interests of expediency, other people would have to get involved in enhancing what we have.

…

On Tue, 1 Mar 2022 at 07:17, Bob Andrews ***@***.***> wrote: Well, to me it sounds like a specific division algorithm being present shouldnt be what is stopping this. This change should be split into two different things anyway, compiler support, and then a floating point library that provides the fp primitives. The library can then be improved later (and it should be possible to replace it entirely, eg by one that uses the ROM of the target computer). I wouldn't be too worried about execution speed either, floats *will* be borderline slow. As with most other things in the library, size is likely a more important resource, so (large) LUTs arent really what we want either. In any case, a PR that adds those things would be a good start :) — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZN324SHJBI7KPZE5W3U5YDGFANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mrdudz]

For the standard datatypes the compiler should do what the standard says - for 16bit floats we can use the half-float format (that also some compilers implement for certain DSPs etc.) for that matter. https://en.wikipedia.org/wiki/Half-precision_floating-point_format

[groessler]

a division operation on 64-bit floats is likely to take more than an entire NTSC frame in order to finish the calculation, which is definitely entering the realm of absurdity.

Depends on what you want to achieve. Calcuation of PI for example doesn't care about video frames...

[aquishix]

There is no such thing as code that is "written correctly". There is code that compiles or doesn't compile. Behavior of compiled code from the same source can be different from compiler to compiler, which is part of why C can be maddening to deal with. Given that this madness is operative for int types, I see no reason why floats should be any different. I'm saying that the C specification is inconsistent in the first place and you're not addressing that point, unless there's just an implicit thing here that the degree of inconsistency is itself up to the specification -- if that's what you're really saying, sure. And I think that's not worth preserving. You're not going to just drop much code from a 16, 32, or 64 bit machine into an 8 bit machine and get it to behave the same way anyway. The approach to memory management is/was vastly different across these different architectures. In the case of the NES, bank switching rules the day and you can't naively use malloc as you would on a 386. That's another reason why the specification should be treated more loosely in the context of the 6502. The point of implementing a C compiler for the 6502 is to get nice syntax to work with for custom code on whatever system it is; the standard library would be impossible or meaningless to port to many different 6502-based systems. Same goes for a lot (most?) of other C libraries. Yes, it would make cc65 not-really-C, but it's *already* not-really-C in practice if not in theory. The C syntax is still something that a lot of people cut their teeth on and would find comfortable to work in in such a scenario -- much more than some other language. And integration with ca65 is the killer feature of cc65 for us; we have no interest in moving to some other C-like language/compiler/runtime/whatever because we're sticking to ca65 for our current project.

…

On Thu, 3 Mar 2022 at 19:38, Bob Andrews ***@***.***> wrote: The reason I don't agree with that is that there is plenty of C code that depends implicitly on "int" being a 32-bit data type. You can compile the same code with a compiler that treats "int" like a 16-bit data type and the code would then behave completely differently. Sure. And there is a lot of very old C code that relies on int being 16bit and which is equally broken However, code that is writte correctly and which does only rely on what the C standard specifies should work in the way the C standard specifies - no more, but no less. — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZPIJ6LGYQ7RYSFTFW3U6FLPRANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[ProxyPlayerHD]

interesting, i had no idea C11 added offical support for half precision floats!
though is the F actually uppercase? the only data type i can think of that has an uppercase letter is _Bool, and i always hated that because pretty much everything else in the language is lowercase, so why bother with uppercase?

anyways you could easily define those in <float.h> like this:

typedef half _Float16;
typedef float _Float32;
typedef double _Float64;

#define _float16 _Float16   // lowercase versions for convenience
#define _float32 _Float32
#define _float64 _Float64

though i'm kinda disappointed they don't use the stdint naming convension: float16_t, float32_t, and float64_t

[zezba9000]

What is the suggested alternative here? I'm running into this issue.
On windows with version: cc65.exe V2.17 - Git 462d809

Getting error: Floating point type is currently unsupported

[oliverschmidt]

I don't see any viable workaround / alternative :-(

[zezba9000]

FixedPoints are the work around. Didn't think of it when I posted.
#799

Would be cool if fixed-points were just used as floats in the cc65 compiler as they're probably the only efficient way to represent decimals anyway for 6502 based systems.

[mrdudz]

that would be quite terrible actually, fixed point behaves very differently and need special care

[zezba9000]

Sure point is you need some kind of decimal system to do many kinds of operations. It not being built into the cc65 compiler really makes porting hard.

I noticed your proj: https://github.com/mrdudz/cc65-floatlib
Does that work pretty well?

[mrdudz]

it "should" work. i have never really tested it because infact... i have not needed floats once in 30 years =)

[mrdudz]

so what do you have so far? a floating point library (conforming to what standard?)? compiler support?

[aquishix]

so what do you have so far? a floating point library (conforming to what standard?)? compiler support?

I implemented addition, subtraction, and multiplication of the 16-bit floating point standard called binary16 specified in IEEE-754-2008 via the ca65 macro assembler. In addition, I have implemented 6502 branching opcode compatible comparison subroutines, bidirectional casting from floats and ints, and approximations for sin and cos. All of this includes to-the-bit accuracy, verified by unit testing every single possible pair of inputs via a custom built 6502 partial emulator that my friend wrote. (He is my CTO and business partner as well.) I came up with an approach to division that is unorthodox but would be very high performance, but it would definitely be binary16 specific; it has not been implemented yet.

It's technically implied by what I've already said, but my code handles subnormals correctly, which is, of course, an unholy beast. I've been musing that that's the reason why everyone before me has given up or not even tried. I'm crazy and obsessive enough to go through with it. ;)

Given the knowledge and experience I've built up on this project, I should be able to re-implement all of the same subroutines with 32-bit and 64-bit IEEE-754 floats.

I did all of the work on binary16 in about 3-4 weeks, part time. I can probably have all of 32-bit/64-bit ready for you guys within a few months. But I wanted to talk about licensing because I'd like my company to retain the copyleft on it if possible.

There are some other issues as well, because I don't really feel like making my code conform to fp.h that Greg has on github, or whatever interface you want to use. I'm taking a different approach in my own codebase that is incompatible with what a compiler needs, but anyone competent enough to work on this project should be able to take my library's source code and modify it as needed.

Again, I'd prefer to continue the discussion off of github, especially because Microsoft has purchased it. I use bitbucket instead. I keep this account only for random things like this.

[zezba9000]

Don't want to derail this but not sure how MS owning GitHub is a negative or changes anything?

[aquishix]

I don't like communicating via github. I don't like using github.

[zezba9000]

Thats cool but GitHub has the largest community of developers. Its a pretty good place for making connections.

[aquishix]

Thats cool but GitHub has the largest community of developers. Its a pretty good place for making connections.

Indeed. It didn't stop me from introducing myself here, or using it for various other random purposes. I just don't like using it the way that programmers typically do, and if I can communicate about this off the site, I will. It doesn't seem like an onerous request to me.

[oliverschmidt]

I suggest to discuss this on the cc65 development mailing list.

[aquishix]

I suggest to discuss this on the cc65 development mailing list.

Suggestion taken; thank you!

[oliverschmidt]

You're welcome. Looking forward to it...

[rosenrost]

Is there any progress here or has it been abandoned?

I am almost certainly going to be the person to hand over the 6502 assembly implementation for floating point support in cc65. Does anyone know whom to talk to? I need to ask some questions and coordinate some things in order to proceed, and I am keenly interested in contributing.

I've already done most of the implementation work(from scratch, by hand) because I'm using it in my own company's NES game development, so these are not idle claims. ;)

[aquishix]

There has actually been quite a bit of progress, but there were a few bugs that had to be worked out and other things took priority after that. I’ll confer with Dominic and see how far away we are from pushing the implementation upstream.

…

-Jared

Sent from my iPhone

On Jan 24, 2021, at 10:58 AM, Oliver ***@***.***> wrote:  Is there any progress here or has it been abandoned? I am almost certainly going to be the person to hand over the 6502 assembly implementation for floating point support in cc65. Does anyone know whom to talk to? I need to ask some questions and coordinate some things in order to proceed, and I am keenly interested in contributing. I've already done most of the implementation work(from scratch, by hand) because I'm using it in my own company's NES game development, so these are not idle claims. ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[mrdudz]

So, any progress in the past year? Floating point support would certainly be a feature justifying a release (or even version bump) :)

[polluks]

Well, if I need fp I use vbcc :P

[mrdudz]

Would you please stop with all those comments that contribute nothing? More often than not i get noticed and have to waste time on something that is completely unrelated and serves no purpose at all. Thank you!

[polluks]

Please calm down. Sometimes it's like blasphemy to mention projects of competitors.
There is already an IEEE library and a fast fp library, a matter of fact. Take the challenge, ok?

[mrdudz]

It has nothing to do with mentioning other projects. It has everything to do with spilling random unrelated chatter into the github issues which contribute nothing to the issue and only make me check them just to find out nothing of relevance was posted. Please stop that. Thank you!

[aquishix]

Honestly, no. We've been focused on very different things than the floating point support we had begun to integrate into cc65. That being said, we should probably just hand over what we have and let others refine it. I was having a hard time deciding which division algorithm to use in particular. We'd come up with a fast one that relies on a small LUT, but it had a slight inaccuracy that we haven't yet figured out how to correct. All of the non-LUT approaches are so incredibly slow as to be borderline useless on a real 6502 based computer. I didn't want to submit something to the community that wasn't ready for prime time.

…

On Sat, 12 Feb 2022 at 16:03, Bob Andrews ***@***.***> wrote: So, any progress in the past year? Floating point support would certainly be a feature justifying a release (or even version bump) :) — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZMJ4TS4CLSHD4WCIO3U23DIXANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[aquishix]

Yes -- I've also thought about including the 16-bit floats under a datatype named "half" instead. That would be a perfectly acceptable solution to the problem, but it would incur some search/replacing for code included from other contexts. Do consider the fact that a division operation on 64-bit floats is likely to take more than an entire NTSC frame in order to finish the calculation, which is *definitely* entering the realm of absurdity.

…

On Wed, 2 Mar 2022 at 14:57, Bob Andrews ***@***.***> wrote: For the standard datatypes the compiler should do what the standard says - for 16bit floats we can use the half-float format (that also some compilers implement for certain DSPs etc.) for that matter. https://en.wikipedia.org/wiki/Half-precision_floating-point_format — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZPCIKSAGC5EDBBJV4DU57B25ANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mrdudz]

but it would incur some search/replacing for code included from other contexts.

In my book that is much better than replacing a standard datatype with something completely different and then the program expecting standard datatypes works completely different than expected. One of the big strengths of using a C compiler at all is that it behaves as expected - if you just want something similar to C but much faster, then there are much better solutions than cc65 anyway.

[aquishix]

The reason I don't agree with that is that there is plenty of C code that depends implicitly on "int" being a 32-bit data type. You can compile the same code with a compiler that treats "int" like a 16-bit data type and the code would then behave completely differently. It's an inconsistency in the C specification that I was pointing to. Please don't ignore me this time around.

…

On Thu, 3 Mar 2022 at 06:45, Bob Andrews ***@***.***> wrote: but it would incur some search/replacing for code included from other contexts. In my book that is much better than replacing a standard datatype with something completely different and then the program expecting standard datatypes works completely different than expected. One of the big strengths of using a C compiler at all is that it behaves as expected - if you just want something similar to C but much faster, then there are much better solutions than cc65 anyway. — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZMTH35YRQ4Q4YDXQALU6CQ53ANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mrdudz]

The reason I don't agree with that is that there is plenty of C code that depends implicitly on "int" being a 32-bit data type. You can compile the same code with a compiler that treats "int" like a 16-bit data type and the code would then behave completely differently.

Sure. And there is a lot of very old C code that relies on int being 16bit and which is equally broken

However, code that is writte correctly and which does only rely on what the C standard specifies should work in the way the C standard specifies - no more, but no less.

[mrdudz]

I'm not sure what we are discussing there. Of course there is code that is written correctly and which behaves as the standard dictates - and this is exactly what you can expect from a C compiler. And cc65 has been really good at this in the past - and we are not giving this up. That "int" was never defined to hold a defined number of bits does not change any of this. Programs that rely on a certain int size are simply relying on undefined behaviour, which means the program is simply not written correctly according to the standard. That doesn't mean we are going to ignore the standard either.

To make a long story short: that means "float" needs to behave as the standard dictates. And if we want a different, faster, half accurate float thing, we'll use a different datatype (preferably one that is also standardized).

[ProxyPlayerHD]

small question: is the main problem right now writing the actual floating point routines?

because there are 65xx C compilers out there that have IEEE float support (WDC's C Compiler, VBCC, and Calypsi C, come to my mind), so wouldn't it be an option to just ask the creators of those compilers to either help or just straight up share their floating point routines?
obviously it would still be a lot of work as the routines would have to just adjusted to work with cc65 (especially because of how little it makes use of the ZP right now compared to something like WDC's Compiler), but it saves the writing of the actual math part of the whole thing.

[mrdudz]

No, that is not the main problem, not to me at least :)

[ProxyPlayerHD]

then what is the issue if the functions are already written and stuff? just integrating it into the Compiler?

[mrdudz]

Adding support to the compiler, of course

[aquishix]

(From https://www.cc65.org/doc/cc65-4.html) " Here is a list of differences between the language, the compiler accepts, and the one defined by the ISO standard: - The datatypes "float" and "double" are not available. - C Functions may not return structs (or unions), and structs may not be passed as parameters by value. However, struct assignment *is* possible. - Part of the C library is available only with fastcall calling conventions (see below). It means that you must not mix pointers to those functions with pointers to user-written, not-fastcall functions. - The volatile keyword doesn't have an effect. This is not as bad as it sounds, since the 6502 has so few registers that it isn't possible to keep values in registers anyway. There may be some more minor differences I'm currently not aware of. " These are the *known* violations of the standard. There are probably many more, and those are just the formal ones. As I keep trying to point out, you're living in a dream world if you think you can just drop in C source code from a 16-bit or 32-bit PC and have it compile correctly, let alone behave the same way at runtime. Do you really believe that being unable to write a function that has a struct return type is *less important* than the precision of the floating point standard that "float" uses? How about not being able to pass structs into functions? I'm pretty sure that I've written code that relies heavily on these missing features. I've also written code that would work correctly with reduced "float" precision.

…

On Fri, 4 Mar 2022 at 08:04, Bob Andrews ***@***.***> wrote: I'm not sure what we are discussing there. Of course there is code that is written correctly and which behaves as the standard dictates - and this is exactly what you can expect from a C compiler. And cc65 has been really good at this in the past - and we are not giving this up. That "int" was never defined to hold a defined number of bits does not change any of this. Programs that rely on a certain int size are simply relying on undefined behaviour, which means the program is simply not written correctly according to the standard. That doesn't mean we are going to ignore the standard either. To make a long story short: that means "float" needs to behave as the standard dictates. And if we want a different, faster, half accurate float thing, we'll use a different datatype (preferably one that is also standardized). — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZK3F6XKV534AK7RG6DU6IC6HANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[aquishix]

Well, I can't prove it, but I have a strong suspicion that the reason that "float" and "double" were never implemented in cc65 has a lot more to do with how useless 32-bit and 64-bit floats would be on a typical 6502-based system. Necessity is the mother of invention. Most(?) people using cc65 are using it for NES or C=64 homebrew game development -- both contexts in which floating point data types are basically useless unless you're creating a Mandelbrot generator. Fixed point arithmetic is the only practical alternative for everything else. I wrote my IEEE 754 compliant float library in ca65 assembly because I wanted to prove a few naysayers wrong about the practicality of using floats on the NES. And even though I was successful, it has very limited utility. Even I just wrote a few proofs of concept (including a correct Mandelbrot generator) and then moved back to reality -- fixed point arithmetic. *However*, 16-bit floats are so much faster than 32-bit let alone 64-bit that I can, perhaps, see a little bit of good coming out of implementing them in cc65. Just a little.

…

On Fri, 4 Mar 2022 at 10:04, ProxyPlayerHD ***@***.***> wrote: then what is the issue if the functions are already written and stuff? just integrating it into the Compiler? — Reply to this email directly, view it on GitHub <#171 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6OZNQHXJCL2ZJZLI6DILU6IRATANCNFSM4BKETUSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[mrdudz]

As I keep trying to point out, you're living in a dream world if you think you can just drop in C source code from a 16-bit or 32-bit PC and have it compile correctly, let alone behave the same way at runtime.

Not at all. You are missing the point. Please stop discussing this. It doesnt help anyone.

If we add a datatype "float" to the compiler, it should behave like the standard says. No more no less.

[aquishix]

Don't you dare tell me to stop discussing something. This is not the way you should treat anyone on a comment thread, let alone someone who could be a contributing member to the project.

[ProxyPlayerHD]

ok i did a bit of reading on this, and i gotta say, C is not a very well defined language. especially since the actual standard is not publically available... which is stupid.

anyways, it's commonly known that integer types don't have a strict size, only a minimum size.
char is atleast 8-bits, short is atleast 16-bits, int is atleast 16-bits, long is atleast 32-bits.
in order to be able to tell what size each of them is across different compilers, the C Standard mentions that <limits.h> should be used to define constants that specify what the upper and lower limits of each type are (and how many bits they use)

floating point numbers are pretty much the same. there is no standard float type, it depens on the compiler/hardware.
and like with <limits.h>, <float.h> is supposed to be used to #defined constants that tell the programmer the details of the floating point implementation. (ie what's the radix, what's the size of the exponents, what's the size of the mantissa, etc)

C99 adds offical support for IEEE-754 (aka IEC 60559) floating point numbers, but like with C89, they are not required.
C99's standard draft document says that only if __STDC_IEC_559__ is #defined is the Compiler REQUIRED to implement float as IEEE-754 compliant single precision floating point numbers, and double as IEEE-754 compliant double precision floating point numbers.
long double is a weird case, it doesn't seem to have a strict definition, the document just says: "the long double type matches an IEC 60559 extended format", not "the" extended format, just "an" extended format.

.

so technically you can implement whatever floating point defintion you want and still be perfectly in line with the C standard (as long as your #defines in <float.h> are correct). from Commodore's 8 bit floats, BCD/Decimal floats, to fully compliant IEEE-754 floats.
but honestly there is little reason to not use IEEE-754 floats, while they're slow and not required, they are sort of expected at this point because of how it's basically the most common if not the only floating point defintion still being used.

but personally i'd say, why not just let the programmer decide?
if they define __STDC_IEC_559__ have cc65 use IEEE-754 floats/doubles, if they don't define it, use some smaller more memory and speed efficient float/double implementations (maybe IEEE-754 half precision or some custom version with a byte aligned format).
if a #define doesn't work for this, make it a command line option instead.
something like: --use-ieee754 (using that option should then automatically #define __STDC_IEC_559__ to be compliant with the C99 Standard)

here the document i referenced: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
the draft from 1990 is pretty much indentical when it comes to the floating point stuff, but it only mentions IEEE-754 floats as an example on how floats can be implemented, not as an optional addition to the C Standard.

[mrdudz]

but personally i'd say, why not just let the programmer decide?

The problem there is that you'll need specific handling of every format in the compiler, not just in headers or the library (if that would be the case it'd be a no brainer really). And since IEEE-754 is the defacto standard which everyone (including other 8bit compilers) uses, this is pretty much what we want. There is little point or reason in deviating from that. For the same reason we dont want support for whatever native ROM floating point format (like what CBM basic uses, for example). It'd just be an insane amount of extra work and require a lot of extra code in the compiler to deal with it (the compiler needs to implement the same floating point handling internally to deal with constant expressions and format conversions). Those symbols dont let the user select what the compiler uses for that matter, they indicate the user what the compiler uses (most compilers will not let the user choose, for the mentioned reasons - i have yet to see one that does)

[ProxyPlayerHD]

The problem there is that you'll need specific handling of every format in the compiler

that is true, it would be an enormous amount of extra work. i kinda forgot that in addition to the actual assembly functions the compiler itself also needs to able to handle all those extra data types (which shouldn't be an issue for IEEE-754 as cc65 is compiled on modern hardware that supports those natively)

overall, i still agree that there is little reason to not use IEEE-754 for cc65.
and if it isn't too much work i think adding IEEE-754 compliant half precicion floating point numbers ie half would be a good memory/speed efficient alternative to the 32-bit and 64-bit float/double.

i also hope this means some reworking will be done of how much ZP cc65 uses, because just the 64-bit multiplication/division i did in my fixed point library were a pain due to the lack of predefined temporary ZP registers... tmp1..4 and ptr1..4 just don't cut it for 64 bit math and they will likely be a pain for floating point math as well.

most compilers will not let the user choose, for the mentioned reasons - i have yet to see one that does

Calypsi C is the only one that i can think of that allows you to choose if you want double to be 64-bit or 32-bit (ie a copy of float)

[mrdudz]

overall, i still agree that there is little reason to not use IEEE-754 for cc65.
and if it isn't too much work i think adding IEEE-754 compliant half precicion floating point numbers ie half would be a good memory/speed efficient alternative to the 32-bit and 64-bit float/double.

yes, exactly. i'd even omit doubles for a start

Calypsi C is the only one that i can think of that allows you to choose if you want double to be 64-bit or 32-bit (ie a copy of float)

thats not really a different format though, this i have seen elsewhere too (i think gcc can do this too somehow)

[domgetter]

16-bit float is clearly a winner for cc65. It matches the size of int and as @ProxyPlayerHD pointed out, it adheres to the standard, and is well-specified in IEEE-754-2008.

The fears of "compiler complexity" are unfounded. Having a few extra cases here and there to deal with 2 vs 4 bytes may be a little tedious, but it isn't the end of the world by any stretch of the imagination.

If anything, the spread of opinions in the thread is evidence of the position that a lot of this should be up to the programmer.

[ProxyPlayerHD]

i don't recall specifically saying that 16-bit floats conform to the C standard, just that ANY floating point implementation does.

and i still think that float should be 32-bit, and that half (16-bit IEEE floating point) could be added as a non-standard alternative for anyone who doesn't have the speed or memory to spare for float or double, but still wants to use fractional numbers.
i mean seriously, the other compilers i mentioned also use IEEE 32-bit floats (and even 64-bit doubles), so why is it so controversial to add the same in cc65? especially if half does get added, which would give cc65 an edge over the other compilers which don't have that option.

If anything, the spread of opinions in the thread is evidence of the position that a lot of this should be up to the programmer.

after some thinking, i don't agree with that.
giving the programmer the power to define the width of data types means that it will break existing functions that relies on exact sizes...
for example pre-made libraries or assembly functions that were made in the assumption that floats are 32-bit, only for a user to compiler a program with 16-bit floats and then complain that the libraries don't work.
overall this would just add extra work for both the user and library programmers, as multiple libraries would have to be written and the user would have to choose the correct one for whatever float width they're using.

so yea, 32-bit floats with 16-bit half thrown into the mix, and maybe 64-bit doubles.

[mrdudz]

so yea, 32-bit floats with 16-bit half thrown into the mix, and maybe 64-bit doubles.

yup

[polluks]

So short float will be called __fp16 or _Float16 as defined in the C11 extension ISO/IEC TS 18661-3:2015?

[mrdudz]

So short float will be called __fp16 or _Float16 as defined in the C11 extension ISO/IEC TS 18661-3:2015?

If there is actually something standard, sure, we should adopt that

[pebmeister]

I found this which may be helpful
http://archive.6502.org/publications/dr_dobbs_journal_selected_articles/floating_point_routines_for_the_6502.pdf

[mrdudz]

I have started implementing floats, starting with regular IEEE488 32bit floats, in #1777

[groessler]

On 5/11/22 01:33, Paul Baxter wrote: I found this which may be helpful http://archive.6502.org/publications/dr_dobbs_journal_selected_articles/floating_point_routines_for_the_6502.pdf

This might also be helpful.

…

Message ID: ***@***.***> www.jhauser.us/arithmetic/SoftFloat.html

[mrdudz]

I am using berkeley softfloat already :) So at least for the time being the library half is "solved" - at least its good enough to update and test the compiler.