Menu
▾
▴
#599 Implement IEEE-754 compliant float and double
Adding double support should be a lot easier now that most backends support 64 bit integer types.
The most feasible path to compliant floating point support routines would likely be a "simple" update from the ancient libgcc code in SDCC's tree to more modern libgcc/glibc soft-fp code.
Berkeley SoftFloat looks usable, too.
As an intermediate step one could add float-to/from-double conversion functions and wrappers for all other support routines. That would add support for the data type double based on the existing float code.
Related
Do we really want IEEE compliance? IEEE compliance as a command-line option? The C requirements on floating-point types are less strict than the IEEE ones. E.g. a C-compliant double could be implemented using 48 bits instead of the 64 required for IEEE-compliance.
Currently SDCC has an IEEE-like float (using the IEEE representation, but not supporting denormalized numbers).
The perfect solution would be someone really looking into this question, and implementing one or more solutions. That would require someone with some background in C, numerics, SDCC and familiar with architectures supported by SDCC, would take maybe half a year to a year. Could be done as a master's thesis. Besides standard textbooks (such as the "Handbook of Floating-Point Arithmetic" and "Elementary Functions: Algorithms and Implementation") and historic floating-point implementations, I'd also recommend also looking into historic implementations, the works of Claude-Pierre Jeannerod and Guillaume Revy, and the implementation for ST231 (http://flip.gforge.inria.fr/).
But until someone finds the time for that task, a simpler solution to quickly get a C-compliant (no matter if IEEE-compliant) double and long double would be good to have.
Philipp
I note in the SDCC support files that the 8051 is the only platform with an assembly floating point library.
Recently, I finished a mostly standard (like SDCC) IEEE 32 bit floating point library, for z80, z180, and z80n devices, that could be integrated into the same files in a similar way to the 8051 support. The key benefit would be to greatly improve the performance of these platforms in floating point, but it would be another code path to maintain.
I think it would be best to stick to the intrinsic functions in assembly, and retain the derived exponential and trigonometric functions from the cephes library, etc.
If there was interest, then I could submit a patch.
Let me know, please.
This proposal sounds like something that should have its own feature request ticket.
I doubt that many people have read it in here.
I really think that double and long double support is asking too much of any tiny 8-bit CPU. If you need that, you should look out for another core.
I would be far more interested in supporting short/half float or fixed point arithmetic.
I've now been able to take a brief look at glibc soft-fp and have to say that it is not suitable for microcontrollers at all.
Berkeley SoftFloat, on the other hand, has just become even more interesting because I've now managed to compile it for STM8 and Z80. (Slightly modified, but even that didn't work back in March 2018. Now, with a more recent SDCC, it does.)
That C89-library supports IEEE-754 compliant 16, 32, 64, 80 and 128 bit floating-point types.
In my opinion, the 16, 32 and 64 bit types are the most interesting, the latter two because a lot of code silently expects that the standard extension in Annex F (IEC 60559 floating-point arithmetic) is implemented.
But since that standard extension allows double and long double to map to the same type, I don't see any good reason to add compiler support for 80 or 128 bit formats. If anyone desperately needs those, they can still use the library functions directly.
It's probably a good idea to let the user choose between floating-point implementations (not everyone is a fan of the BSD license) and also between 32 and 64 bit double, while e.g. long double coud be fixed at 64.
With a library like that, at least nobody would have to invest a year of their time in new floating-point code.
How does Berkeley SoftFloat compare to our current 32-bit float in performance?
I don't see a problem with the 3-clause BSD license. Which problems are there?
A 32-bit double is not C-standard compliant. I don't think offering that option makes sense.
I haven't seen progress on short float on the C side since the previous WG14 London meeting, but apparently it has been slowly moving forward on the C++ side, so there is hope for it to make it into C2X.
Philipp
I don't know, yet. In any case, there is an INLINE_LEVEL macro for fine tuning.
Flame wars, mostly.
The rationale behind a 32-bit double option would be compatibility with previous SDCC releases combined with type promotion in variadic functions (less overhead).
The avr-gcc wiki page has recently been updated to mention that avr-gcc version 10 will support 64 bit double and long double types.
If configured appropriately, there will reportedly be the command line options
-mdouble=Nand-mlong-double=N(N is 32 or 64) and the new built-in macros__SIZEOF_DOUBLE__and__SIZEOF_LONG_DOUBLE__.If and when support gets added to SDCC, the adoption of these option and macro names would be desirable.
Just to follow up, now this thread has woken up for 2020, the z88dk math32 32bit SDCC compliant solution is available for z80, z180, and z80n processors. For simplicity, I suggest just the intrinsic and derived functions (written in assembly, and using the z180 and z80n multiply hardware) would be useful for SDCC.
The higher level functions remain in C, and it makes no difference where they are sourced from.
I prepare set of the minimum code, if desired.