>Fpr a lpt of these devices the gain would be between using existing OS
>provided (non IEEE) 'short float' formats. Right now for example on the
>Sinclair machines there is a full rather nice non IEEE floating point
>built into the ROM but while it's useful it's rather "interesting" to use
>from SDCC. Similarly on the Amstrad CPC boxes.
>For me "short float" or similar would actually be useful as a "native non
>IEEE" format indicator - but then you've got to know how to encode floats
>and what the target float format is which is a large can of worms.
For the spectrum, cpc and other machines, their float implementations are
not technically "short". Without having a closer look, I think most
are 32-bit which is the same size as SDCC's current float and IEEE single
precision.
SDCC tries to be standards compliant so I think it would prefer to define
these float formats to have the widths expected of them -- short float
might be 16-bit, float 32-bit and double 64-bit. On some MCUs there might
be an intermediate size that is efficiently implemented like 48-bit for
the z80. Since 64-bit doubles are going to be painful in generated code
I think I would agree with Philip that double perhaps could be shortened
to take advantage of that on those MCUs. Maybe long double could be used
to mean at least 64-bits.
If SDCC itself defines these types short float, float, double to be
16-bit wide, 32-bit wide, 48-(64-)bit wide respectively and it defines
a float interface using those widths for each float type, then it's
possible to allow the library to assign meaning to the bits and therefore
implement whatever float format it wants to, IEEE or not.
This is almost how we do things for SDCC now. For the z80, SDCC does
define a float interface via its compiler primitives. Its float type
is 32 bits wide. We write the code implementing these primitives in
the specific math library linked against and that math library also
defines new functions as required by math.h. Because the float type
is known to be 32-bits, the register interface for all math functions is
known. So far there is nothing that says what the format of the 32-bit
float is. The one thing that stops us from using whatever format we
want is that SDCC itself must encode float constants seen in C source
and it does so assuming the float format defined by its own float package.
That means we have to insert float format translation code between the
compiler and float package, so every SDCC float primitive and math.h function
has a call at the beginning to convert the SDCC format to the math package
format and every returned float value sees a conversion from the math package
format to the SDCC format. *IF* SDCC could be instructed to encode
float constants in a way defined at compile time that is consistent with the
float package linked against, we can get rid of all the float format
conversion and SDCC's float type is now entirely defined by the math
library rather than the compiler, except for bit width. This is what I
am offering up for consideration.
Specifically for the z80, as mentioned before, we have two standalone
float packages that are 48-bit. For SDCC we have one of these packages
available that is selected on the compile line when "-lm" appears.
Because SDCC only knows about 32-bit floats, there is conversion code
that translates from SDCC's 32-bit format to the 48-bit format and
vice versa. So although math is done in 48-bits, SDCC only sees 32-bits
of it. If SDCC adopts a 48-bit double, we could keep the precision.
If SDCC can be told to encode double constants using this library's
float format at compile time, we can eliminate the runtime conversion
code.
We will also have adapters for system-specific float libraries. The
zx spectrum as you mentioned has a 32-bit float type. We will do it
the same way by writing the SDCC float primitives to use the zx's
rom calculator. Then the math.h functions will also be written
to use the rom calculator. This set of float functions may be selected
on the compile line with "-lmzx". Because the zx's float format
does not align with SDCC's built in format, we have to insert
conversion code into these functions. Again, if SDCC can be told
to encode float constants using the zx format at compile time, we
can eliminate that conversion code.
Likewise for the cpc and msx, we can generate libraries linked
against on the compile line to use their float implementation
in rom using, eg, "-lmcpc" and "-lmsx1".
In this scheme how is SDCC told which float format encoding
to use and who is responsible for defining them? Another poster
mentioned SDCC may not want to clutter itself with a bunch of
legacy requirements. If that's the case, perhaps SDCC could
supply a mechanism and then the library implementers could
maintain float conversion code for the float types the library
implements.
The short float type may be 16-bit. We might use that to offer
a 16-bit fixed point type chosen with "-lmfp16" (or something)
that would implement SDCC's defined short float interface.
However, we might also use the short float type to implement
arbitrary precision decimal arithmetic. Such a (simple)
math package exists on the z80 and I would use the 16-bits
as a pointer to the arbitrary precision number in memory.
Write the SDCC primitives in these terms, get SDCC to encode
constants in the right format and we have an arbitrary
precision math library.
By having the compiler define the bit widths for the float
types and a math interface but stopping short of defining
the float formats themselves, you can see how the library
is free to do whatever it wants, IEEE standard or not, and
the library can be tailored to individual MCUs.
SDCC can continue to supply its own default package but
for people maintaining libraries for specific processors
this is a lot of flexibility to gain desired performance.
It is a lot of work for the library authors and that
means most MCUs will not see this taken advantage of
but it would likely happen for the z80 and to some extent
already has.
------------------------------------------------------------------------------
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
