Re: [avr-libc-dev] fixed point math library

[Sean D'Epagnier]

>> It uses the fixed point support
>> built into gcc for avrs (patch for this also attached), and the math
>> library uses the s15.16 fixed point type.  Other fixed point types are
>> supported by avr-gcc, but not for trig operations yet.
>
> Very good, the main type I am interested in is an s.15 type, with voccasional
> use of  s15.16 types to carry intermediate results, or in the case of a DSP
> filter s.15 for tap coefficients and tap registers with an s.31 accumulator
> for the target of the MAC operation.
>

s.15 is fully supported for basic operations +-*/  it even makes use
of the fmuls instructions for optimal multiplication.

The trig functions don't use it because this type can't represent
integers at all (besides -1)  .. but it would work reasonably well to
call the s15.16 functions.. you could get a slight performance
increase with functions specific for only s.15, and it would be
relatively easy to write.   If you did this, you could reuse a lot of
it for s7.8 versions too since they are both two bytes.

avr-gcc can efficiently convert between types as needed, so it's fast
to convert from s.15 to s15.16 etc...

> <snip>
>
>> Initially I would like any feedback on this patch.  There are various
>> ways to improve it, but they would require work.  I would appreciate
>> it if someone could attempt to build gcc and avr-libc with these
>> patches.
>
> Well, as soon as I free up from the other project, I will try it out, and
> look for a way to contribute.
>

Maybe you can write support for s.31 type.  Right now it is already
supported, but via a c library. If you wrote native assembly it would
be much faster.

I only supported:
s.7
.8
s.15
.16
s7.8
8.8
s15.16
16.16

With native assembly so far.  Other types up to s63.64 and 64.64 are
available but only via a c library.

> One comment on trig/transcendental functions: It is often far more important
> to have monotonic results than "more accurate" results.  Any iterative
> algorithm, or any algorithm that takes differences (in my case, robot
> navigation and robot motion control, which involves looking at differences)
> the 1st derivative of the result is much more important  to numeric
> stability than being correct to the last bit.  Having the slope between two
> results behave strangely causes no end of convergence problems.
>

Hmm, I think that the trig functions I have should do ok then, but you
can test them to be sure.

> Also, in case you haven't seen it, I did find this paper from Austria:
> "Fixed Point Library According to ISO/IEC Standard DTR 18037 for Atmel AVR
> Processors" (Elmenreich, Rosenblattl, Wolf)
>
> This seems to be a link:
> http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/a/av/avrfix/avrfix.pdf
> and there is a power point that goes with it someplace.  If you have trouble
> finding them I can do more digging for better links.
>
> I haven't had a chance to dig into the paper in detail, but it looked like
> it had some useful analysis.  The authors put out their code under LGPL:
>  http://sourceforge.net/projects/avrfix -- I haven't even had a chance to
> download it yet to see what it contains.
>
> What you are doing is very useful.  Thanks for driving it.
>

I have seen avrfix, but it is fully written in c, and doesn't use
fixed point support in the compiler, so the result is it is very slow,
much slower than using floating point.    It's only real advantage is
that it is smaller, but now my assembly routines are even smaller.

Sean