On Sun, Oct 7, 2012 at 12:56 PM, Weddington, Eric <eric.wedding...@atmel.com> wrote: >> -----Original Message----- >> From: avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org >> [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org] On >> Behalf Of Georg-Johann Lay >> Sent: Sunday, October 07, 2012 2:26 AM >> To: avr-gcc-list@nongnu.org >> Subject: [avr-gcc-list] May avr-libc use functions from libgcc? >> >> Is is legitimate that assembler functions in avr-libc call functions >> implemented in libgcc directly? >> >> This would make some assumptions, e.g. on naming conventions. >> >> Calling directly can lead so smaller and faster code because some >> functions in libgcc implement a special ABI. >> >> For example __udivmodqi4 (unsigned 8-bit quotient and remainder) does >> not clobber X or Z so that the caller can hold values in these registers >> across the call which reduces register pressure in the caller. >> >> 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 >> >> 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. > > I'm ok with this using knowledge of libgcc in avr-libc, if the benefits are > faster, and especially smaller, code.
That makes sense to me. -- Gaby _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
