[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] Missed Optimisation ?
From: |
Alex Eremeenkov |
Subject: |
Re: [avr-chat] Missed Optimisation ? |
Date: |
Wed, 02 Mar 2011 22:10:39 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; uk; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 |
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.
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(...)
{
...
}
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?
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 so, is the compiler allowed to use that information?
Nobody will build projects that have all-in-one instead modular
development.
You are like to use functions,classes, modules, libraries in development.
Why compilers development should have all in one big heap for have
possibilities for some cloudy optimization?
If so, did the given example allow the suggested optimization?
As it was every time by a years: if compiler optimizations not enough,
developers write critical functions on assembler.
- 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, 2011/03/02
- Re: [avr-chat] Missed Optimisation ?,
Alex Eremeenkov <=
- 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
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/05