Re: [avr-chat] Missed Optimisation ?

[Michael Hennebry]

On Tue, 1 Mar 2011, Graham Davies wrote:

> Michael Hennebry wrote:
>
> > On further examination, I did find a "volatile uint32_t result;".
> > In context, I would guess that it was a complete
> > statement in the same file as the ISR.
> > Note the absence of attributes.
> > How could result not be in internal SRAM?
>
> You may know that 'result' is going to be in internal SRAM, but you know 
> things that the compiler doesn't.  The compiler just puts the variable in 
> memory.

If the compiler doesn't kow it, how would I?
The compiler knows the toolchain better than I do.

> > The compiler doesn't know whether the programmer is nuts.
>
> ... and is not required to make the program behave sensibly when the 
> programmer does something nutty like calling an ISR as an ordinary function.
>
> > That is not the same as blinding it to
> > things it can see in the source code.
>
> The compiler is not allowed to infer that just because a variable is only 
> accessed from one place in the source code it can see, that it is not also 
> accessed from source code it cannot see during the translation.
>
> > Can you give an example that cannot be
> > eliminated by looking at the source code?
>
> No, but that's not the point.  The compiler can't see all the source code of 
> the project at the same time.  If a variable is accessed by two different

It doesn't need to.
It only needs
volatile uint32_t result;  // definition, not just a declation

ISR(...)
{
...
}
> threads of execution that appear in two different translation units, the 
> compiler cannot know that it must avoid certain optimizations unless the 
> programmer "tells it" using the volatile storage qualifier.
>
> > PORTB |= _BV(3);
> > is usually compiled as an SBI instruction.
> > Following the volatile rules blindly
> > would require at least two accesses.
>
> Strictly speaking, this AVR-specific optimization violates the language 
> specification, given that PORTB is volatile.  The compiler should generate

I disagree.
The SBI instrution is equilavent to
{
uint8_t sreg=SREG;
cli();
uint8_t portb=PORTB | _BV(3);
PORTB=portb;
SREG=SREG;
}
Admittedly volatile implies "I know something you don't know."
That said, if the compiler understands the hardware,
there are limits on what that could be and the as-if rule applies.

> P.S.  We may be descending into a personal argument.  I would be happy at 
> this point to say "we're both right, from out different points of view, but 
> are perhaps not explaining it well to each other".  OK?

I think we are close.
It seems to me that the sticking points are:
Can the compiler know that result is in internal SRAM?
If so, is the compiler allowed to use that information?
If so, did the given example allow the suggested optimization?

With regard to the first,
that is why I've been harping on definition rather than the declaration.
If result were merely an extern,
the compiler would not know whether result was defined by another C file
or located with a linker option.
Suppose the processor cannot use external memory
and suppose ISR.c:
#include ...

volatile uint32_t result;  // definition, not just a declation

ISR(...)
{
...
}

The compiler will issue instructions for accessing result.
The instructions will be of the sort used on internal SRAM.
result will therefore be either in internal SRAM or in IO space.
None of the memory segments in the linker script include IO space.
result will be in internal SRAM.
All this from ISR.c and a compiler option.

With regard to the second, I think that it cannot be settled by reason.
To me it is clear that it should do so.

To me, the third is also clear.second, I think that it cannot be settled
by reason.
To me it is clear that it should do so.

To me, the third is also clear.
Were the emitted code and the suggested optimization
surrounded by code to disable and restore interrupts,
they would be exactly equivalent from the point of view of C standards.
Both would be allowed.
As disabling interrupts only affects atomicity
and avr-gcc generally ingores atomicity,
Both are allowed without disabling interrups.

--
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."