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

[Georg-Johann Lay]

David Brown schrieb:
> Georg-Johann Lay wrote:

> > 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.
>
> That's true in theory - but embedded programmers are used to the 
> difference between theory and practice (there's an interesting 
> discussion about the theory and practice of "volatile" on 
> comp.arch.embedded at the moment).  In theory, the compiler should 
> generate good code no matter how the source code is structured.  In 
> practice, the experienced programmer can do a lot to help the tools. 
> avr-gcc *does* do a good job with most code - I do much less 
> re-structuring of my source code for avr-gcc than I do for most other 
> compilers (I use a lot of compilers for a lot of different targets).

Yes, I agree with you. You can help the tools a lot. At the moment I am 
in the strange and interesting situation just the other way round: Not 
tweaking a compiler to please a hardware, but to give a recommendation 
for a new ISA design to please a compiler (GCC).

> > 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.
> It is certainly true that you want to keep such compiler-helpful 
> structuring to a minimum.  But if you are trying to write efficient code 
> (rather than emphasising portability or development speed or other 
> priorities), you *must* be familiar with your compiler and the types of 
> code it generates for particular sequences of input.  You can very 
> quickly learn some basic tricks that can make a great difference to the 
> generated code with very little re-structuring of the source code.  A 
> prime example is to use 8-bit data rather than traditional C "int" where 
> possible.  Another case in point is to prefer explicit "if" conditionals 
> rather than trying to calculate a conditional expression, such as was 
> done here (if you are using a heavily pipelined processor, the opposite 
> is true).
GCC will more and more transform and canonicalize such stuff, i.e. it 
will turn if-else into flat (with respect to code flow) algebraic code. 
The backend can fix that, but the jumps then are implicit, no more 
explicit. And I was astonished to see examples where int instead of char 
yield better code. The cases are rare, but they exist.

Georg-Johann