avr-chat
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]