
From:  GeorgJohann Lay 
Subject:  Re: [avrgcclist] May avrlibc use functions from libgcc? 
Date:  Sun, 07 Oct 2012 13:00:59 +0200 
Useragent:  Thunderbird 2.0.0.24 (Windows/20100228) 
Erik Christiansen schrieb:
On 07.10.12 10:25, GeorgJohann Lay wrote:Are such calls "allowed" in avrlibc provided  The special interface is documented in libgcc sources and mentions that avrlibc 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 avrlibc, namely the upcoming fixedpoint 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 homebrew 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 qformat 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 fixedpoint 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(1x*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] 