I know it's not right to float an idea without means to implement it, but it just seems too good not to be recorded. For better times. So the floating point in Z80 compilers is implemented similar to the gnu floatlib (see: https://opensource.apple.com/source/gcc ... .auto.html ) It is a set of functions implemented in C/asm that implement the IEEE 754 standard.

But most Z80 games and software that uses floating point does not use IEEE 754 standard ... because it is too slow for the micros.

So the idea is very simple: add compiler switches to allow user to ask compiler to use fixed point n.m (where n and m is 8,16,24) library instead. When fixed point is used the compiler should link different floatlib library and change behavior (for example, when it sees float a=123.56f it whould compile this to fixed point format).

This way people could write games that require fast floating point operations - without using separate calculation engines.

## An idea for faster floating point in Z80 compilers

### Re: An idea for faster floating point in Z80 compilers

The way we addressed the maths library is rather flexible, we now have a lot of precision options and others targetted to specific versions.

IMHO it a fixed point implementation could be even slower than a low precision floating point library, it could be interesting for high variable precision, though.

If you think at it in most of the cases you can simulate the fixed point by dealing with powers of integer or long types with the further benefit of a local custom optimization in you games where is is preferable to use integers.

The isin() / icos() functions in example get an integer argument and give an integer result to be divided by 256, you can first do the multiplications with whichever coefficient you have and apply the division afterwards limiting the effect of truncating to integer.

IMHO it a fixed point implementation could be even slower than a low precision floating point library, it could be interesting for high variable precision, though.

If you think at it in most of the cases you can simulate the fixed point by dealing with powers of integer or long types with the further benefit of a local custom optimization in you games where is is preferable to use integers.

The isin() / icos() functions in example get an integer argument and give an integer result to be divided by 256, you can first do the multiplications with whichever coefficient you have and apply the division afterwards limiting the effect of truncating to integer.

### Re: An idea for faster floating point in Z80 compilers

There are floating point libraries ranging from 16-bit (for your z80 LLM) through to 64-bit available already, and they are configured using compile switches (see aliases provided at below link)So the idea is very simple: add compiler switches to allow user to ask compiler to use fixed point n.m (where n and m is 8,16,24) library instead.

Fixed point in 8.8- bits is also intrinsic and can be used with no complications.

For detail see here

https://github.com/z88dk/z88dk/wiki/Cla ... -Libraries

Once you get above 16-bits a floating point solution will be faster, it comes down to the amount of data that needs to be shuffled through the limited registers available.

As you point out, there’s also a trade off between mantissa precision and performance. For both the math32 and math16 implementation I erred on the side of accuracy. But it is easy to build special solutions (i.e. games) using less iteration for division and square root, and using fewer polynomial coefficients for calculation of power and trigonometric functions.

You can read about these possibilities in the math32 reader, and look into the implementation code, where the choices are simple cutouts.

https://github.com/z88dk/z88dk/tree/mas ... h32#readme

Cheers, Phillip