[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] May avr-libc use functions from libgcc?
Date: Sun, 07 Oct 2012 13:00:59 +0200
User-agent: Thunderbird (Windows/20100228)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]