>I don't think any of us disagree with the convenience thing. But
>is anyone actually using 16 bit floats for their apps or projects?
>The biggest problem is the 11 bit precision -- 8 bit MCUs probably
>calculate using 16 bits of precision and then unpack-pack into the
>half float format. Right now I am really really interested in
>seeing a real life 8-bit MCU program that uses 16 bit floats, or
>something very close in spirit...
I don't disagree with you. I don't think there is any significant
advantage to having a short float in addition to a regular float
on MCUs without a hardware implementation. On these small MCUs,
fp is slow and I was arguing the only meaningful gain could be
in code size but I don't think there would be much difference in
code size between a short float and regular float implementation.
Convenience is important as we all agree and I also agree with
Kusta that there are applications where a large dynamic range
is needed such that fixed point would not be most appropriate.
However I do see a need for a fast fixed point type and my point
was you may be able to design at the compiler end to allow the
library to decide that a short float might actually be implemented
as fixed point. With the right design the burden of float
definition is moved from the compiler to the library and when this
is done you can be very flexible about what the float formats
actually are. There is a sticking point about how float constants
in C code should be translated to its binary representation (how
does the compiler know when the float format is defined in the
library?)
There is another advantage in this for sdcc in particular since it
aims to support a variety of MCUs. The most natural floating point
format for a specific MCU is going to be shaped by number of registers,
register widths and instruction set. On the z80, the largest natural
float size is 48-bits. The reason is two floating point operands
can be held in registers BCDEHL and BCDEHL' in the exx set. Few(er)
memory operations are required to implement the math functions and
the float package can be re-entrant because no static memory is used
to hold parameters. Obviously such a format is not going to be a
universal fit for all MCUs so this ability to let the library decide
also allows efficient implementations with variable characteristics
for different MCUs.
>> [snip]
>> 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
>Ummm... where are the floating point declarations?
Have a look at line 125. There are no float declarations but there
is floating point math. The program is written to be small in the
source code sense so there's probably no reason to use floating point
other than to reduce the number of characters typed.
>Very nice, if only someone had a metric truckload of time to
>expend on it.
You'd be surprised what accumulates over a few decades for some of
these legacy processors. The z80 in particular has a large body
of C-related libraries written in assembly language and still
many active hobbyists contributing.
What I am suggesting would take a lot of work in the library end,
enough work that for most MCUs it would never be taken advantage
of. But for the z80, do it, and eventually it will come.
>I don't think it would be as
>easy as defining widths, and maintaining such things is something
>dedicated retrocomputing developers need to do, IMHO we should not
>burden folks like the SDCC devs with a ton of legacy requirements.
I'm not suggesting SDCC do it. There's a reason why its C library
is written in C -- you instantly have portable code that presents
the same API to every target. The cost is larger and slower code
than alternative specialized libraries written in assembly language
that might be implemented for specific MCUs. It shouldn't be SDCC's
job to maintain such disparate libraries. That would be the job of
the people maintaining those specialized libraries.
------------------------------------------------------------------------------
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
