Re: [avr-gcc-list] efficiency of assigning bits

[Erik Walthinsen]

E. Weddington wrote:
> And for everyone else: this is why it pays to understand what your 
> compiler is doing; take a look at the resulting assembly of your C code 
> and never assume anything.

Yup.  A C compiler is great and all for building constrained 
applications, but can never produce code as tight as hand-written 
assembly.  OTOH development is insanely easier.  However, there are 
almost always ways you can tweak the C code to coerce the compiler into 
producing smaller or faster code, if you screw with it enough.

Chips like the ATtiny15 (with no RAM whatsoever, just the 32 registers) 
can be even more interesting, with the compiler's choice of registers 
for all your variables.  Depending on the order of chunks of code, I've 
found that gcc (3.4.3) can sometimes make some really blatantly bad 
choices, causing significant temp-register use when it's totally 
unnecessary.  But some experimental re-orderings of code tend to give me 
a sequence that utterly changes the register allocation and collapses 
the bad parts.  I need to try gcc 4.0 when it's ready for daily and 
production AVR use...

(The application in question is a servo controller that orients a set of 
geophones to North according to a Honeywell compass, in a device that 
gets dropped several hundred meters into a holes all over the world. 
Isreal got the first one, Oman has one, etc.  It's replacing an older 
totally analog subsystem of the same function and is supposed to 
function "identically", making the task that much harder.  All on a 
1.25" diameter 100% through-hole hand-assembled board, in 1KB of code.)