Re: [avr-gcc-list] Program Space String & optimization

[David Brown]

>
> On Dec 14, 2005, at 8:57 AM, Joerg Wunsch wrote:
>
> >> volatile PGM_P txt= P_Txt;
> >
> > Your volatile qualifier is at the wrong place.  You're marking the
> > object "txt" points to as volatile, not the pointer itself.  Change
> > that into
> >
> > PGM_P volatile txt = P_Txt;
> >
> > and it will work.
>
> Believe that is correct. But the other thing that was tripping him is
> in general all function calls are effectively volatile as well. Call
> a function and expect it will be called simply because you said to,
> the the optimizer probably won't descend into the function and decide
> it can be skipped. If the function is inlined then all bets are off.
>
> do{} while( (a=pgm_read_byte(txt)) );  // Wait for null char
>
> While pgm_read_byte(txt) looks like a function call it is totally macro.
>
> I don't believe this is a problem with the compiler at all, it did
> exactly what it was told it could do.
>
> --
> David Kelly N4HHE, address@hidden
>

Actually, gcc is getting steadily better at optomising function calls -
there is no reason to assume that function calls are effectively volatile.
Under normal optomisation, the compiler will use what it knows about
previously defined functions to determine if they can be re-ordered,
inlined, or skipped entirely.  Some standard library functions are handled
as special cases, and it is possible to use function attributes in header
files to tell the compiler more (such as "const" or "pure") giving the
compiler lots more freedom to move around the function calls.  With -O2 and
above, "unit-at-a-time" compilation allows the compiler to use information
about functions later in the same unit, and if you've specified several C
files at the same time, it can use information about all of them.  Thus
assuming that function calls are volatile is dangerous.

mvh.,

David