View topic - [TUT][C]Optimization and the importance of volatile in GCC

Search

[TUT][C]Optimization and the importance of volatile in GCC
Previous 1, 2 All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR Tutorials

Author

Message

clawson

Posted: Aug 14, 2011 - 11:32 AM

Joined: Jul 18, 2005
Posts: 62324
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

the compiler complains

Yes, you are using the later version of delay.h which has been fixed to emit an error when it is used wrong - this is a distinct improvement as it forces users to actually bother reading the manual rather than simply guessing at how the function probably works.

As for when to optimise: always and often - why would you want a compiler to generate sub-optimal code?

(debugging is the one exception but you don't deploy the debug code - you deploy the release code and you want it as efficient as possible).

_________________

valleyman

Posted: Aug 15, 2011 - 02:16 AM

Joined: Jul 25, 2011
Posts: 49

clawson wrote:

(debugging is the one exception but you don't deploy the debug code - you deploy the release code and you want it as efficient as possible).

(BTW, AS5 only defaults to -O1 in Debug configuration; in "Release" configuration, the default is -Os. Debug, in turn, is the default configuration for new project template as well as in all sample applications I downloaded from Atmel.) When I wrote my first program from scratch (using a blank template), I didn't use volatile. Tests worked as expected. Had I changed to Release configuration, I would be unpleasantly surprised to see all my elaborate arithmetic only resulted in a steady blink. (After reading this, I purposely removed volatile and switched to Release. Yes, all variations are gone.)

The tutorial seems to suggest that I shouldn't be throwing volatile to all variables or compiler will not optimise as much as it should. How do I know when I should force volatile even though I do not expect another program or peripheral to alter a variable? I can see that interrupt handler should be considered another program. But there's another example in which a non-empty loop also needs a volatile declaration to maintain the "expected," or designed, behaviour. Should every "loop variable" be volatile?

clawson

Posted: Aug 15, 2011 - 09:22 AM

Joined: Jul 18, 2005
Posts: 62324
Location: (using avr-gcc in) Finchingfield, Essex, England

Atmel, you have to realise, are like kids with a new toy who haven't quite worked out how it actually works. Any regular user of avr-gcc knows that the -O0 they use for "Debug" is not acceptable in any circumstance. Some idiot at Atmel thought this was the right choice for "Debug" build. It is not. It's only purpose is for the compiler writers to check the unoptimized code that is initially generated. While it does make programs that can be easily debugged because of the straight one-to-many relation between C source and generated Asm it is utterly and totally pointless to debug that code as it, in no way, represents the code you are finally going to be running. Try adjusting the watchdog or changing the CLKPR register or set the JTD bit using a program built -O0 and it will never work. At the very least Atmel should have used -O1 for "Debug" but even then it's going to behave differently to the final -Os/-O3 program. What Atmel should do is improve the debugger so it can more easily track locals that are cached into registers and encourage users to debug -Os code.

As I say the best solution is to use -Os and simply don't use 'volatile'. Instead debug in the mixed C+Asm view (by which you also quickly learn AVR assembler) and work out which machine registers locals are cached into and watch those rather than using the "Watch window". If you have a problem with this then only while debugging a localised section of the code just temporarily make any locals you think you need to watch there 'volatile'. When you are happy that code section works then remove the volatile.

This rule for volatile has nothing to do with FAQ#1. Any variable that is accessed within two threads of execution must ALWAYS be volatile whether you want to watch it in a debugger or not.

But keep this thought in mind - every time you make a variable volatile you make your program bigger and slower. So do it with care and don't hand out the 'volatile's like they were sweeties.

_________________

ashokok

Posted: Aug 16, 2011 - 06:36 AM

Joined: Aug 11, 2003
Posts: 113
Location: Bangalore INDIA

we are using -Os -mcall-prologues optimization.
Avr_libc_user manual say that this is the most universal best optimization level can you explain about this optimization and also what all the consideration to be taken care for using this optimization.

P.Ashok Kumar

clawson

Posted: Aug 16, 2011 - 09:06 AM

Joined: Jul 18, 2005
Posts: 62324
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

can you explain about this optimization

I'd suggest this is the ultimate source:

http://gcc.gnu.org/onlinedocs/gcc-4.3.6 ... logues-953
http://www.nongnu.org/avr-libc/user-man ... tools.html

_________________

abcminiuser

Posted: Aug 16, 2011 - 12:04 PM

Joined: Jan 23, 2004
Posts: 9830
Location: Trondheim, Norway

Quote:

Normally each ISR has a unique "prologue" and "epilogue" - a few housekeeping instructions to push and pop various portions of the AVR's register set which the ISR needs for its own use, to prevent the existing values from being lost. This is great for low-latency ISRs, as only the registers used are saved and restored.

If you have a large set of ISRs each with a lengthy prologue and epilogue, there can be a lot of flash memory wasted storing the individual ISR prologue/epilogue code. To combat this, you can use the -mcall-prologues switch. This will make every ISR call a single unified ISR prologue and epilogue routine, which will in turn save and restore the entire AVR register set regardless of which registers are actually required in the ISR.

The downside is that every ISR now has a lot more latency, due to the extra CALL/RET instruction pairs to jump to the unified prologue/epilogue functions, and because you now have to wait for all the registers to be saved and restored regardless of which are used. The upside is a space savings if the space taken up by the one unified prologue/epilogue function pair is less than the individual ISR prologue/epilogue sequences.

TLDR; It increases ISR latency, but will reduce overall flash memory consumption if you have a lot of complex ISR handlers in your application.

- Dean Twisted Evil