[avr-gcc-list] Re: C vs. assembly performance

[Nicholas Vinen]

> If I wanted fast and small, I'd have done it in ASM. But half of the point
> of this exercise was to get my feet wet with C.
> So, both points accomplished. I have GCC up under AVR studio, a working
> project, and I feel reasonably confident with the code.
>   
Despite avr-gcc being fairly dim about optimisations*, the results can
be pretty reasonable. I had to write one program for a Mega48 in
assembly language to get it fast enough. The goal was to linearly
interpolate 16 bit values from a table stored in flash fast enough to
output a 192kHz signal with the processor running at 20MHz. That gives
just over 100 cycles to fetch the values, do the interpolation, output
the value and update the pointers. I couldn't do it in C, even with
inline assembly, but managed it in assembly. Part of the trick was
storing everything in registers, which JUST fit for two channels.
However, the C compiler was able to do it in something like 160-180
cycles. So I wouldn't discount C performance being quite acceptable if
you are careful.

* On the other hand, it would be great if avr-gcc could perform some
basic optimisations that even a fairly inexperienced amateur could
manage. For example, things like "unsigned char x, y; x = y>>4" could
use the nibble swap instruction rather than four shifts, and things like
"unsigned short a; unsigned char b; b = a>>8" could pretty much just be
a single instruction. These are examples of things I've seen the
compiler waste cycles on, that are fairly obvious. In future if I see
the compiler doing silly things like this, is it worth me posting the
code & assembly output to this list?



Nicholas