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

[Dave N6NZ]

Sean D'Epagnier wrote:
> Hello,
>
> I have recently implemented a fixed point math library in assembly for
> avrs.  I am hoping that it can be a part of avr-libc so it will be
> available to many developers.  Also I welcome anyone who might be able
> to optimize or extend its support.  

First, let me say that I am extremely happy that you have taken this on. 
 I have been collecting data to something very similar.  Unfortunately, 
at the moment I am deep in contract project using "another vendors 
processor" --- with the most awful tools.  (It will be wonderful to get 
back to avr-gcc.)

So... while right at this moment there is no way that I can apply your 
patch and do any work, it is certainly very high on my list of things to 
do when I can return my focus to AVR's.

> 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 
occasional 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.

<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.

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.

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.

-dave

> I also would like to know how the statistics for ram, flash usage and
> cycle count is calculated for the other library functions so they can
> be calculated for fixed point math operations for a comparison.
>
> Thanks,
> Sean
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev