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

[Georg-Johann Lay]

David Brown schrieb:
> Nicholas Vinen wrote:
>
> > OK, I only spent a few minutes looking at old code and I found some 
> > obviously sub-optimal results. It distills down to this:
> >
> > #include <avr/io.h>
> >
> > int main(void) {
> >   unsigned long packet = 0;
> >
> >   while(1) {
> >     if( !(PINC & _BV(PC2)) ) {
> >       packet = (packet<<1)|(((unsigned char)PINC>>1)&1);
> >     }
> >     PORTB = packet;
> >   }
> > }
>
> Did you write the code like this just to test the optimiser?  It 

As far as I understand, it's a stripped down example to demonstrate the 
code bloat in a reproducable way (combileable source).

> However, avr-gcc constantly surprises me in the quality of its code 
> generation - it really is very good, and it has got steadily better 
> through the years.  Sometimes it pays to think a bit about the way your 
> source code is structured, and maybe test out different arrangements.

Source code structure is a concern of the project, not of the compiler.
Even for braindead code that comes from a code generator a compiler is 
supposed to yield good results.

I am inspecting the produced asm in some of my AVR projects with hard 
realtime requirements, too. But I would not encourage anyone to dig in 
the generated asm and try to get best code by re-arranging it or trying 
to find other algebraic representations. That takes a lot of time, and a 
compiler should care for the sources it gets, not the other way round. 
And if your code is intended to be cross-platform, you are stuck. If 
your code changes some 100 source lines away from the critical code, the 
inefficient code can return and you have to rewrite your code again to 
find another representation that avoids the bad code.

Georg-Johann