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
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
