>SDCC currently implements 32-bit float as its only floating-point data type.
>Would you like to see a cheaper one in SDCC, that uses only 16 bits?
>Would you use it?
My answer is yes, sort of (fuller explanation below : )
For any 8-bit microcontroller without hardware floating point, floating point
is not about performance it’s about convenience. There are many examples of C
programs in the wild that use floating point for convenience, here are some
that have been successfully compiled using sdcc for z80 targets but using a 3rd
party z80 library:
One of the world’s smallest chess programs. Shockingly it uses floating point:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/umchess.c?revision=1.2&view=markup
The familiar startrek program from the 70s, directly translated from Basic:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/startrek.c?revision=1.2&view=markup
Whetstone synthetic floating point benchmark. Well this one doesn’t really
count as an application example:
http://z88dk.cvs.sourceforge.net/viewvc/z88dk/z88dk/libsrc/_DEVELOPMENT/EXAMPLES/benchmarks/whetstone.c?revision=1.4&view=markup
Using something for convenience is fine as long as the implementation is
affordable. This is the sticking point with sdcc’s current fp package -- it’s
really large to the point that it can become unusable in non-trivial programs.
For the whetstone example, a native sdcc build eliminating i/o comes to 14k in
size in comparison to a build using sdcc and the 3rd party library coming to
6k. That’s an extra 8k cost for using the native float package in sdcc and it
comes down to the float package being written in C in comparison to the third
party library’s implementation in assembler. Because of the size difference,
it’s unlikely that the startrek example above could be compiled for many z80
targets using native sdcc due to memory size limitations.
I don’t think changing to a smaller float type will reduce the code cost and I
think that’s where a fundamental improvement in sdcc could be found. You will
speed it up by n times because loops will be shorter but I’d argue that's not
the central goal when using fp on a z80.
Our needs are a little bit different. We have several floating point libraries
that are selected between on the compile line. You’re choosing between two
different z80 floating point packages, both of which are 48-bit because, as it
turns out, 48-bit is the maximum convenient size for floats on a z80. Then
it’s also possible to use a native floating point implementation that may be
present as system software on a specific target (zx spectrum, cpc, msx, and so
on). Most of these are 32-bit with small variations in in-memory format and
register assignments. Sdcc only understands a single 32-bit floating point
format so the libraries have to adapt by performing runtime conversions between
sdcc’s fp format and the format used by whatever math package is selected on
the compile line.
A new short float format I don't think is going to solve any problems on any
microcontroller that doesn’t have a corresponding native hardware
implementation. The standard is simply trying to accommodate graphics
processors which do define these half float formats. However, a short fixed
point format would probably be well served on micros like the z80.
What I am getting at is, ideally, we’d be able to tell the compiler what the
floating point format is at compile time so that these runtime conversions
don’t have to be made. That might be pie in the sky; another alternative is to
define generic float operations on short floats, floats and/or doubles with the
compiler assuming each type is x,y,z bits in width. It is then the
responsibility of the library to assign meaning to the bits and to implement
the defined float interface. This would solve our runtime conversion problem
and it would allow us to define short floats to actually be fixed point where
advantage could be gained from that without taking away from the possibility of
other math libraries defining short floats differently such as ieee.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
