avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Strange compile behaviour


From: Han Hoekstra
Subject: RE: [avr-gcc-list] Strange compile behaviour
Date: Tue, 2 Feb 2010 13:57:52 +0100

> > What I see no is that when the while loop at the beginning is compiled
> > into the code, everything is running OK, but when I comment it out, so
> > it is not in de code, the stack check fails, indicating that __bss_end
> > and __bss_end + 1 no longer have the specific test values.
> >
> 
> If you are using interrupts than you might (by accident) be waiting for
> the moment that no interrupts are being executed. And thus no extra
> stack usage during your function execution.
> 
> The code size increment is due to a smart optimization. You force
> app_TXIncomming to be zero before continuing, gcc notes it and does not
> do a multiply that saves some pointer calculation and therefore space.
> So your loop is doing something after all ;)
> 
> This also indicates app_TXIncomming as not being volatile? Or a gcc
> optimizer bug.
> 
> HTH,
> 
> Wouter

Ok, I did not expect AVR-GCC to be so smart that it would omit the pointer
calculations, because the while loop would cause app_TXIncomming to be 0,
that is nice optimizing.

However, what I don't understand is that the while loop does not cause some
stack overflow, because I have decreased the array to be only a single
element, so app_TXIncomming is always 0, so the while loop should therefore
never loop.

It is true that there are a number of interrupts running in the background,
but they run in both cases, so that should not make a difference.
Oh and yes, app_TXIncomming is not volatile, making it volatile does not
change the behavior, the code always sees a stack overflow when the while
loop is commented out and no stack overflow when the while loop is included.

I will continue to trace my problem, the issue with the difference in
generated assembly is now clear to me, I can cross that of my list of things
to look at. Thanks for the explanation.

Greetings,
   Han
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4827 (20100202) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]