|
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 2.0.0.24 (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 wikiWell, 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 LSBFor 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
[Prev in Thread] | Current Thread | [Next in Thread] |