Re: [cc65-devel] IEEE 754 Floating Point Support in cc65

[Jared H. <ja...@so...>]

Oliver,

Here are the answers to your questions, in order:

- Yes, absolutely!

- Right.  I wrote all of this from scratch in ca65 Assembler, involving no one else's code or libraries whatsoever.

- I am now; it's the same as the zlib license, which is pretty straightforward.  I am willing to put it under the zlib license, but I am curious about whether or not I can apply that license to my library *first* and *then* contribute it to the cc65 project, so that I'm acknowledged as the original author; I also want my company name to be on it.  It seems to me that that's the only way to make both parties satisfied.  Does that actually make sense?  I've never contributed to an open source project before, and although I'm pretty familiar with the various open source / free software licenses out there, I've never had to deal with a situation like this before.  Another concern is that I want to be able to release the library in standalone Assembly form so that people can use it in NES games that are written in pure 6502 Assembly.

- I do not assume that this would be a one-time-shot; I can easily imagine fixing issues that come up, but I don't know how much time I'll have over the next 9-12 months.  My company (Something Nerdy Studios) is a startup and our first project is an original NES game.  We're going to be pretty busy with that until it's out the door, but I would do what I could to help out with bug fixes in the meantime.  I would gladly "maintain" the code if that's all you're referring to.  Is there an implication of some other kind of maintenance, here...?  (Like updating the floating point code to conform to a different interface in the compiler source code, for instance.)

- I am prepared to gain the knowledge necessary to integrate my library with the compiler myself, but that would *certainly* delay the integration effort.  Honestly, as I tried to indicate, I was hoping that someone who is far more experienced and skilled in that area would help me adapt the library to the cc65 codebase.  It would be exciting and useful for me to learn that stuff, but it's not my area of expertise.  I wasn't aware until you pointed it out that the original cc65 author had abandoned the project.  Is there *anyone* else working on this, or is it effectively a dead project?  I'm a little disappointed that this is the state of affairs.  Granted, it's kind of a niche thing because it's such an old architecture and most people are willing to just write things in Assembly when they target 6502-based systems, but I've always regarded C as *the* general purpose programming language.

Cheers,

Jared Hoag
Founder / CEO
Something Nerdy Studios LLC

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, July 20, 2019 10:09 AM, Oliver Schmidt <ol...@we...> wrote:

> Hi Jared,
>
> First of all let me state that I'm sure that the cc65 community is in general for sure very interested in floating point support in cc65.
>
> It seems to me that it is important that there are no misunderstandings on what we are talking about here. So let me start with some stupid(?) questions:
>
> - Are we talking about a contribution that is supposed to become part of the cc65 delivery?
>
> - That contribution that becomes part of the cc65 delivery is the complete implementation you describe. There's no dependency on some 3rd part library, right?
>
> - Are you aware of the cc65 license? I presume that you are willing to put your contribution under the same license.
>
> - Do you consider this contribution a one-time-shot or can you imagine to fix issues in the code in questions? Do you see yourself to put some amount of time into maintaining the code you contribute?
>
> - Are you prepared to gain the knowledge you need to integrate such a contribution with the compiler (and optimizer(?)) yourself? Or are you presuming to get support from the cc65 community. I don't know if you are aware that the original author of cc65 isn't working on the project anymore (https://www.cc65.org/). At least I know about nothing of the compiler internals and can't offer any support.
>
> Regards,
> Oliver
>
> On Fri, Jul 19, 2019 at 4:25 PM Jared Hoag <ja...@so...> wrote:
>
>> Greetings.
>>
>> I introduced myself and my work thus far on the related github issue (#171); Oliver stepped in and suggested that I come here, so here I am.
>>
>> Here's a revised recap:
>>
>> ---
>>
>> Almost certainly, I am going to be the person to hand over the 6502 assembly implementation for floating point support in cc65.  I need to ask some questions and coordinate some things in order to proceed, but I am keenly interested in contributing...very soon.
>>
>> I've already done most of the hard parts 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. ;)
>>
>> Here's the list of what I have implemented thus far via the ca65 macro assembler, conforming to the 16-bit floating point standard called binary16 specified in IEEE 754-2008:
>>
>> * addition
>> * subtraction
>> * multiplication
>>
>> Beyond those, I have implemented 6502 branching opcode compatible comparison subroutines, bidirectional casting from floats and ints, and reasonable approximations for sin and cos.  I can make bit-perfect sin, cos, log, exp, etc subroutines and intend to, but I haven't needed to thus far in my own codebase because we're valuing performance over accuracy given the context of NES game development.
>>
>> All 3 of those core arithmetic operations enjoy to-the-bit accuracy, verified by unit testing every single possible pair of inputs via a custom built partial 6502 emulator that my friend Dominic Muller wrote in C. (He is my CTO and business partner as well.)  He also wrote Lua code that displays binary16 floats in plain text, so that code could become the basis for printf-compatible text conversions in cc65.  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 dealing with the huge number of edge and corner cases. ;)
>>
>> 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.  I basically reserve a few bytes of zeropage RAM and use them as float registers instead of using the stack, because we don't have true functions in ca65 and I regard using the stack for this purpose to have little benefit, at extra computational cost.
>>
>> We have optimized and unoptimized versions of my addition and subtraction algorithms, but multiplication has not yet been optimized.  Even in unoptimized form, I was able to create a demo ROM that shows characters moving around the screen in trigonometric patterns, with the parameterized paths being generated real time (intra-frame) instead of hard coded.  Some of this stuff can even be done during vblank!
>>
>> My breakthrough realization that motivated me to do all this is that 32-bit and 64-bit floats are too computationally expensive to use real time on the NES, but 16-bit ones _might not be_, and I feel like I've accomplished a large measure of success along that front.  But after I got to the point where I'm at now, I realized that I could re-use a lot of the work and go ahead and implement 32-bit and 64-bit floats for cc65 as well in order to complete the project / bring it into conformance with the C standard.  My understanding is that despite all the allowed bit width variance for non-float data types, half precision (I.e., binary16) would not be acceptable for a correct C implementation.  However, I do think it would be nice to include binary16 in cc65 for people who want to write games in cc65 but get the performance benefits of 16-bit data types.
>>
>> Also, one of my near-term projects it to fully implement a 64-bit fixed point math library and the casting code to go back and forth between fixed and floating point data types, in order to allow game developers to pick and choose which world they want to do math in according to need.  For instance, store numbers as binary16 in ROM in order to halve the amount of required ROM space but then cast them to fixed point at runtime for even faster computation.
>>
>> I look forward to the ensuing discussion.  If anyone is interested in seeing a demonstration, I could record videos of my Mandelbrot demo I wrote for the NES, and my trig path demo.
>>
>> Thanks,
>>
>> Jared Hoag
>> Founder / CEO
>> Something Nerdy Studios LLC
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> _______________________________________________________
>> cc6...@li...
>> https://lists.sourceforge.net/lists/listinfo/cc65-devel