[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: |
Tue, 1 Mar 2011 11:28:29 -0600 (CST) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
On Tue, 1 Mar 2011, Graham Davies wrote:
Erik wrote:
Errrrr ... Bob, if "result" is in RAM, and so can't be changed by
We haven't been told how or if "result" is defined.
It might have only been declared in source
code and located with a linker option.
hardware, and interrupts have not been reenabled (we're in an ISR),
then how can "result" be volatile?
ISRs can be called like ordinary functions.
The linker could have that information,
but the compiler normally wouldn't.
It's volatile if Bob has declared it volatile. The compiler doesn't know
whether Bob is right or wrong to declare it volatile. Bob is right to
The compiler could know.
If the definition is in the same file as the ISR,
the compiler could know that "result" need not be volatile,
though not in this case.
In this case, if the definition is in the same file as the ISR,
the compiler would know that "result" is in internal SRAM.
From this, the compiler could correctly conclude that
neither fetches nor stores have side-effects.
Three of the fetches and stores are therefore redundant.
In the presence of other threads,
atomicity rears its ugly head regardless of optimization,
but avr-gcc generally ignores atomicity.
This might be useful:
#define nonvolatile(x)(*(typeof(x)*)&(x))
declare it volatile if, as well as being accessed in this ISR, it is accessed
by non-interrupt code. As I've already mentioned, if that is the case,
interrupts should be disabled during the non-interrupt code access.
Writing in assembler because you don't properly understand the C language is,
in my opinion, a very bad reason for taking longer to do the job and opening
up a whole new can of worms in the C-to-assembler interface, which you may
not properly understand either.
I agree, though in the case of ISRs,
the C-to-assembler interface is pretty simple.
--
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 ?, bob, 2011/03/01
- RE: [avr-chat] Missed Optimisation ?, Colin O'Flynn, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?, Erik Christiansen, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?, bob, 2011/03/01
- Message not available
- [avr-chat] Re: Fasching, bob, 2011/03/02
- Re: [avr-chat] Re: Fasching, Erik Christiansen, 2011/03/02
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/01
- RE: [avr-chat] Missed Optimisation ?, Colin O'Flynn, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/01
- Re: [avr-chat] Missed Optimisation ?,
Michael Hennebry <=
RE: [avr-chat] Missed Optimisation ?, Boyapati, Anitha, 2011/03/02
RE: [avr-chat] Missed Optimisation ?, Boyapati, Anitha, 2011/03/02
Re: [avr-chat] Missed Optimisation ?, bob, 2011/03/01
Re: [avr-chat] Missed Optimisation ?, bob, 2011/03/01
Re: [avr-chat] Missed Optimisation ?, Graham Davies, 2011/03/01