Re: [avr-gcc-list] May avr-libc use functions from libgcc?

[Georg-Johann Lay]

Erik Christiansen schrieb:
> On 07.10.12 10:25, Georg-Johann Lay wrote:
> > Are such calls "allowed" in avr-libc provided
> >
> > - The special interface is documented in libgcc sources and mentions
> >   that avr-libc makes use of the special interface
> >
> > - The functions with their special interface are documented, e.g. in
> >   the GCC wiki
>
> Well, that's how I would do it in a project of mine, FWIW.
>
> > The question is for code that is not yet part of avr-libc, namely the
> > upcoming fixed-point support; it's not about optimizing code that's
> > already there.
> >
> > Sean said that CORDIC shows bad rounding for asin, for example.
> >
> > I played around with a home-brew asin approach that has no rounding
> > issues.  The performance of the implementation can be improved if
> > knowledge of libgcc is used.
>
> Holy cow, the approach is fine, I figure, just from the perspectives of
> consistent code behaviour and reuse. Add performance improvements and
> your case is irresistible, I reckon.

Actually I don't know if the performance compared to CORDIC is 
reasonable because I have no CORDIC benchmark results.

My intuition says that CORDIC will beat code size, for speed I have no 
clue, and precision and monotony is the great pro for my approach.

I once tried CORDIC with sin and cos and I observed that there is quite 
some noise on the result, namely up to 7 LSB for 15 fractional bits, 
i.e. 3 bits of the result are lost.  And that's for a function that's 
well behaved (monotone, C(oo), any derivative limited by 1, ...)

The only performance results I have so far is for 0.16 q-format square 
roots which is needed for asin:

speed in Ticks:  240 (with MUL)    340 (no MUL)
size in Bytes:    80 (with MUL)     60 (no MUL)

Speed is the maximum over all 2^16 inputs.

Maybe someone can tell if these results are reasonable?

This square root comes in a "floor" and a "round to nearest" flavor. 
Maximum absolute errors are (again over all inputs):

sqrt floor: -1 LSB   < err <= 0 LSB
sqrt round: -1/2 LSB < err < 1/2 LSB

For the fixed-point asin the first results indicate that the computation 
will need around 700 - 800 ticks (asinf needs ~2500) which is 50 ticks 
per bit so CORDIC is likely faster.

For a s.15 implementation of CORDIC sin / cos I found 560 ticks (with 
MUL) and 280 bytes flash.

My approach for asin consumes 560 bytes flash (dunno if it is reasonable 
to compare that with CORDIC sin to estimate CORDIC asin).

> I've only tried basic CORDIC to produce sin and cos. I didn't know that
> asin was feasible with the method.

AFAIK that approach uses

   asin(x) = atan2(x, sqrt(1-x*x))

so that it's clear you accumulate rounding errors and is must behave bad 
close to the singularity at x=1.

Johann