[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-chat] Missed Optimisation ?

From: Colin O'Flynn
Subject: RE: [avr-chat] Missed Optimisation ?
Date: Tue, 1 Mar 2011 15:33:18 +0100

Hi Bob,

One consideration is that reading or writing might have side-effects on a
memory-mapped peripheral.

So if you were accessing a peripheral with a pointer to a volatile uint32_t,
and issue the |= command, you might actually be expecting the CPU to perform
the memory read & write. The simple act of reading the memory could clear a
flag for example.

My personal thought process with the volatile keyword is I assume the
compiler does *all* memory accesses, even the unnecessary ones.



-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of bob
Sent: March 1, 2011 3:28 PM
To: address@hidden
Subject: Re: [avr-chat] Missed Optimisation ?

>> So, I think that the compiler is doing exactly what it should do.
> Have to agree, 'cos the code can break if it doesn't respect a genuine
> volatile.
> Mind you, if "result" is genuinely volatile, then it can change between
> the |= and the >>=, so we could be right shifting the other thread's
> value, couldn't we?
> <$.02>
> Over 25 years I've always written ISRs in assembler. That has made them
> easy to optimise, predictable in behaviour, and independent of compiler
> "improvements" in the event of having to use another version. (Not that
> in-line asm stuff, rather a proper linked-in asm file. Lots easier. ;-)
> Oh, 'n don't have to argue with the compiler about what's "volatile"
> either.
> </$.02>
> Erik
Hi Erik ! (and Graham and Jan and Alex)
I suppose 'big machines' might interrupt in the interrupt (as can the
avr, but it doesn't unless you make it).
In the construct <load value> < OR > <save value>, it just doesn't make
sense to me to cheat on the OR'ing but not on the load/save part.
Your thread argument is true but would be broken by the current compiler
action (e.g. if the value of result was changed externally between load
and OR and save) but then you would never be able to guarantee anything.
I think that, in an interrupt where no other interrupt has been enabled
(i.e. in the interrupt code itself), then it would be better to save
some bytes.
But maybe that's too complicated.
You are right in saying that ISRs are better written in assembler (and
linked), only then do you have 'full control'.
I will do this in assembler anyway, it was just a point I wanted to
discuss with the list - thanks for doing just that.
It still seems to me that cheating on a part of the code, but not the
other part is a bit screwy :-)



AVR-chat mailing list

reply via email to

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