[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] Missed Optimisation ?
From: |
Michael Hennebry |
Subject: |
Re: [avr-chat] Missed Optimisation ? |
Date: |
Wed, 2 Mar 2011 11:20:00 -0600 (CST) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
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."
- Re: [avr-chat] Missed Optimisation ?, (continued)
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?,
Michael Hennebry <=
- Re: [avr-chat] Missed Optimisation ?, Alex Eremeenkov, 2011/03/02
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/02
- Re: [avr-chat] Missed Optimisation ?, Alex Eremeenkov, 2011/03/02
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/03
- Message not available
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/03
- Re: [avr-chat] Missed Optimisation ?, Pertti Kellomäki, 2011/03/04
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/04
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/05
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/05
- Re: [avr-chat] Missed Optimisation ?, Michael Hennebry, 2011/03/05