Comments (58)
That we want integral datatypes to work as the standard dictates is simply not up for discussion.
from cc65.
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
from cc65.
I have in the meantime updated and fixed and tested my little library, btw - so it can be used, if you really wanted.
from cc65.
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 :)
from cc65.
from cc65.
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
from cc65.
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...
from cc65.
from cc65.
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
from cc65.
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
from cc65.
I don't see any viable workaround / alternative :-(
from cc65.
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.
from cc65.
that would be quite terrible actually, fixed point behaves very differently and need special care
from cc65.
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?
from cc65.
it "should" work. i have never really tested it because infact... i have not needed floats once in 30 years =)
from cc65.
so what do you have so far? a floating point library (conforming to what standard?)? compiler support?
from cc65.
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.
from cc65.
Don't want to derail this but not sure how MS owning GitHub is a negative or changes anything?
from cc65.
I don't like communicating via github. I don't like using github.
from cc65.
Thats cool but GitHub has the largest community of developers. Its a pretty good place for making connections.
from cc65.
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.
from cc65.
I suggest to discuss this on the cc65 development mailing list.
from cc65.
I suggest to discuss this on the cc65 development mailing list.
Suggestion taken; thank you!
from cc65.
You're welcome. Looking forward to it...
from cc65.
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. ;)
from cc65.
from cc65.
So, any progress in the past year? Floating point support would certainly be a feature justifying a release (or even version bump) :)
from cc65.
Well, if I need fp I use vbcc :P
from cc65.
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!
from cc65.
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?
from cc65.
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!
from cc65.
from cc65.
from cc65.
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.
from cc65.
from cc65.
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.
from cc65.
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).
from cc65.
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.
from cc65.
No, that is not the main problem, not to me at least :)
from cc65.
then what is the issue if the functions are already written and stuff? just integrating it into the Compiler?
from cc65.
Adding support to the compiler, of course
from cc65.
from cc65.
from cc65.
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.
from cc65.
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.
from cc65.
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.
from cc65.
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)
from cc65.
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)
from cc65.
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)
from cc65.
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.
from cc65.
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 float
s with 16-bit half
thrown into the mix, and maybe 64-bit doubles
.
from cc65.
so yea, 32-bit floats with 16-bit half thrown into the mix, and maybe 64-bit doubles.
yup
from cc65.
So short float will be called __fp16
or _Float16
as defined in the C11 extension ISO/IEC TS 18661-3:2015?
from cc65.
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
from cc65.
I found this which may be helpful
http://archive.6502.org/publications/dr_dobbs_journal_selected_articles/floating_point_routines_for_the_6502.pdf
from cc65.
I have started implementing floats, starting with regular IEEE488 32bit floats, in #1777
from cc65.
from cc65.
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.
from cc65.
Related Issues (20)
- dbgfile misses linker generated symbols
- data goes into the wrong section/segment when segment is changed more than once HOT 8
- Option to omit version info in generated source files
- Lynx: Uploader implementation and configuration does not work HOT 1
- Suggestion: Adding line with callback functions to TGI HOT 1
- compiler does not include .dbg lines for function internally scoped variables
- test_gets.c fails on windows HOT 2
- Bitwise operation with boolean operand wrong when optimised HOT 3
- [lib?] printf/scanf format specification for targets with translated charset? HOT 4
- Node.js 16 actions are deprecated. HOT 1
- void VAR = {} data is being stored as 2 bytes HOT 1
- ca65: Can't use .sizeof(.word) HOT 1
- memcpy/memmove upwards vs downwards HOT 10
- make -j test/parallel make for tests is broken HOT 5
- CC65 "-W" option does not suppress the specified warnings. HOT 2
- [cc65] cc65 extension on enumerator constants conflicted with C23 HOT 3
- compiler warning on cc65/scanner.c
- [Feature Request, ca65] Add ".if" directives for register sizes HOT 4
- [cc65] Wrong handling of enum/struct/union types without member lists in local declarations HOT 1
- Add output file and segments to the .map files. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cc65.