Re: [avr-gcc-list] code optimisation

[Trevor White]

Many thanks for all your comments. I have been working on my first full 
blown project with an AVR and GCC. Before this project I have worked in 
assembler. C gives many great benefits and I have enjoyed using it. The 
code I write is readable and my brain is not taken up with assembler 
coding techniques. The structure of C seems to just allow me to get on 
with writing code.

The cost of this is that my code seems large and I dont really know how 
long the code will take. I have to measure it on a scope and toggle port 
pins. I have used 8k already and now seem to spend time optimizing so I 
can carry on writing code. This is where I have found that re-writing 
certain lines seems to help. For example...

   temp = ~temp;
   temp += 1024
 
I have not tried this but am using it off the top of my head to show 
abstract ( to me ) code optimization.

   temp = (~(temp) + 1024);

I seem to find things like this above sometimes make better code. 
Sometimes a switch..case flow control works better than If statements, 
sometimes it is the other way round. So I was really wondering if there 
were golden rules and if there were any specific to gcc for avr.

Trev









Geoffrey Wossum wrote:

> On Wednesday 18 August 2004 9:39 am, Graham Davies wrote:
>  
>
> > I think Dave could be right that optimization should not be an early
> > concern, if ever.  However, those guys he quoted were not from the embedded
> > world and sometimes things can be different down here.
> >    
>
> The AVR architecture is much faster than you'd (well, I'd) expect from an 
> 8-bit MCU.  gcc also seems to do a good job optimizing for it.  Very rarely 
> have I had to optimize code I have written for an AVR.  When I do, the stuff 
> I do isn't AVR or gcc specific.  It's standard optimization stuff like 
> hoisting invariants out of loop bodies, amortizing calculations, use lookup 
> tables, etc.  Stuff that you could do on any architecture with any compiler.
>
> That being said, although I never do anything special for speed, I do jump 
> through some hoops to keep my memory usage (both RAM and flash) down.  
> However, once again, the memory optimization I do isn't AVR or gcc specific.
>
>  
>
> > I'm wondering if Trevor is coming at AVR GCC from a compiler that has a
> > lousy built-in code optimizer?  I have used ZiLOG's ZDS II for the Z8
> > Encore, which is a good example of this.  By inspecting the generated code
> > I was able to figure out all kinds of dumb tricks to reduce the size and
> > increase the speed. 
> >    
>
> Similar situation with cc65 (a free 6502 compiler).  cc65 actually does an 
> excellent job of optimizing code, considering how unkind the 6502 
> architecture is to high-level languages.  But I've still had to figure out 
> all kinds of odd tricks to speed up the code it generated in order to get the 
> performance I needed from the code.  My experience is that writing odd 
> looking code to try to get extra performance out of most "modern" compilers 
> (gcc, MSVC, ICC) is ranges from having no effect, to actually producing worse 
> code.
>
> ---
> Geoffrey Wossum
> Software Engineer
> Long Range Systems - http://www.pager.net
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
>
>
>