[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Re: C vs. assembly performance
Date: Sat, 28 Feb 2009 22:08:31 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]