|Subject:||Re: [avr-gcc-list] efficiency of assigning bits|
|Date:||Mon, 14 Mar 2005 12:32:31 -0800|
|User-agent:||Debian Thunderbird 1.0 (X11/20050116)|
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.)
|[Prev in Thread]||Current Thread||[Next in Thread]|