Re: [avr-chat] Missed Optimisation ?

[Michael Hennebry]

On Wed, 2 Mar 2011, Alex Eremeenkov wrote:

> 02.03.2011 19:20, Michael Hennebry writes:
> > 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.
>
>
> You *must* know because you are developer.
> It's only developers responsibility to know what dedicated memory arrays 
> means.
> Compiler doesn't know and shouldn't know what output linker set mean 
> according real world.

Horse hocky.
The compiler is required to know because it is
required to emit the correct kinds of instructions.
volatile uint32_t result;
will go in the same memory space as
uint32_t consequence;

> > It doesn't need to.
> > It only needs
> > volatile uint32_t result;  // definition, not just a declation
> >
> > ISR(...)
> > {
> > ...
> > }
>
> Your example explain only one node from big possibilities tree where some 
> compiler works must generate code.
> You are expect that compiler will generate quite correct code in all 
> variants.
> Agree? So why it generate code that could work quite incorrect in *other* 
> different solutions?

The compiler should generate code that depends on the source.
That is rather the point of a compiler.

> > > 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.
> One more time - compiler it's not a God. It's mostly a state machine only.
> And what it must do - work pretty well. Some inline optimization that could 
> be skipped by compiler, at least theoretically, it's not huge pain for use 
> hi-level abstractions.
> > > 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?
>
> It don't know. It's only linker point.

If it doesn't know, it can't emit correct code.
The code actually emitted, generally regarded as correct,
required just that knowledge.

> > If so, is the compiler allowed to use that information?
>
> Nobody will build projects that have all-in-one instead modular development.

Non sequitor.
The discussion has been about what is visible in a single .c file.

--
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."