Re: [avr-gcc-list] Problem with delay loop

[Paulo Marques]

David Brown wrote:
> Paulo Marques wrote:
> > David Brown wrote:
> > > [...]
> > > it could perhaps reason that since there is no way for anything 
> > > outside the program to find out where the local volatile variable 
> > > resides, there is no way for anything else to influence or use the 
> > > variable, and therefore the "volatile" qualifier can be ignored.
> >
> > This sentence makes no sense at all. The "volatile" is precisely to 
> > warn the compiler that it should not "reason" anything about this 
> > variable.
>
> I think the standards are pretty vague regarding exactly what "volatile" 
> means.  There is nothing (that I know of) in the standards saying where 
> a volatile variable must be allocated.

Yes, I wasn't disputing that either. Only that the compiler could not 
"reason" that it wasn't used.

Note that I'm not arguing the memory/register allocation here. You could 
also have a CPU that had a "register access counter", or something, 
where accessing a CPU register would increase the counter value and you 
wanted to use volatile to make the compiler access the register in the 
loop to increase the counter value.

> > If you give a volatile qualifier to a local variable, it's obvious 
> > that you want it to behave differently from regular local variables, 
> > so I think gcc is doing the best it can, from the weakly defined 
> > volatile semantics.
>
> It may be obvious to *you*, as the author, that you mean "volatile" to 
> work like this.  It certainly works like that on avr-gcc at the moment. 

The "obvious" part here is that you can declare a local variable without 
any modifiers or with the volatile modifier. If the volatile modifier 
makes the compiler generate the same code, then it would be useless. If 
it forces the compiler to not optimize away accesses to that variable, 
then it can have some use.

>  But what appears "obvious" to programmers (even expert experienced 
> programmers), and what the standards say, what the compiler does, and 
> how it all works on the target in question, can be very different 
> things.  When working with bigger cpus with caches and instruction 
> re-ordering, for example, "volatile" is not nearly strong enough to give 
> you the kind of guarantees we take for granted on avr-gcc.

Yes, I follow LKML too, and all the endless threads on memory ordering / 
volatile / SMP races ;)

> > This makes as much sense as saying that any volatile is futile, since 
> > you can compile a program with "-combine -whole-program" and so the 
> > compiler can always "reason" that any variable will not be accessed 
> > outside of its control.
>
> No, it's not quite the same.  In particular, if the variable's address 
> is known outside the code (for example, if it is given a fixed address, 
> such as by the definition of the port I/O registers), then there is no 
> way the compiler could make guarantees about the safety of removing the 
> "volatile". 

I think you're actually agreeing with me that the compiler can not 
optimize global accesses away, but you're saying that it can for local 
variables because their locations aren't known?

What if the CPU had dedicated storage for the stack frame, and accessing 
locations there had side effects unknown to the compiler?

Yes, I'm grasping at straws here, but the bottom line is: if the side 
effects are unknown to the compiler, _they_ _are_ _unknown_ to the 
compiler. It is best not to assume anything.

> Similarly, if different globally accessible functions (such 
> as interrupt functions) accessed the variable, it could not remove the 
> "volatile".  But for local variables within a function, it is much more 
> straightforward to see how such variables could be accessed or addressed.

Well, I could argue that the compiler also knows these functions are 
"interrupt" functions and could assume that any variable modified by 
these functions had to be "treated as volatile", even without the keyword ;)

This would in fact be the best scenario: inside the interrupt functions 
the variables would be accessed as regular variables, but outside they 
would be accessed as volatiles.

> > Note that I'm not disputing that the compiler could in theory use a 
> > register instead. I personally don't think that would be a good idea, 
> > but it might be allowed by the specs. What I'm disputing is that the 
> > compiler _can not_ ignore the volatile and optimize the loop away 
> > entirely. That would be a compiler bug, for sure.
>
> It would certainly be a surprise to many (including me) if it *did* 
> remove the volatile variable in practice.  But I'm not 100% sure that 
> the standards disallow such optimisations - that's all I'm saying.

I hope I'm quoting from the right (currently in use) standard:

"      99. A volatile declaration may be used to describe an object
           corresponding to a memory-mapped input/output port or an
           object  accessed  by  an   asynchronously   interrupting
           function.   Actions  on objects so declared shall not be
           ``optimized out''  by  an  implementation  or  reordered
           except   as   permitted  by  the  rules  for  evaluating
           expressions."

So, I don't think the standards allow the compiler to "optimize out" a 
loop that has a volatile access in it.

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"Prediction is hard. Especially of the future."
Niels Bohr