avr-gcc-list
[Top][All Lists]
Advanced

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

RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os


From: Scott and Roxanne Munns
Subject: RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Date: Mon, 26 May 2008 21:41:41 -0500

David,

I agree that this is a "point of view" thing.  And I will admit that most of
my embedded programming (Coldfire, not AVR) is spent doing C++ programming,
so that may make my view more data-centric than code-centric.

I know that you understand the "critical section" issue, and you are able to
state its requirements much more eloquently than I can.  I would trust your
ability to recognize critical section issues and solve them properly,
whether you think about them in a data-centric way or in a code-centric way.
However, I am amazed how many embedded programmers *don't* understand how to
work with critical sections.  Some developers I have talked to seem to
interpret critical sections as "if some *code* can be executed in two
different contexts, it needs a critical section to handle it".

Maybe if you're talking about two threads accessing a shared code path, and
that code path is also changing the state of shared data objects, that is
correct.  If the developer always protects any shared code paths, the code
will probably be safe in its code sequences, just very slow.

On AVR, at least without an OS installed, there are no threads.  There are
only contexts: mainline code context and interrupt contexts.  Depending on
how the developer writes the code, it is possible that no code may get
shared between contexts, only data.  Ideally, the developer should use
shared functions to modify shared data objects and keep them in a coherent
state, but there is no guarantee they will do that.  They may just clone
code between the interrupt function and the mainline code.  Now there is no
"shared code path".

In my opinion, that is the possible flaw of thinking in a code-centric way.
The developer may think there is no risk (no overlapping code paths), when
the data is actually at risk.

There is probably a corollary to this for a data-centric way of thinking.
Perhaps thinking that the get/set operations need critical sections, and
forgetting that the in-between code sequences that modify a data object are
also a vital part of maintaining overall data object coherency.  In other
words, don't "drop the lock" until you're done modifying the data object!

Either way, it comes down to training a developer about critical sections
and making sure they really understand the core issues.  I guess I've been
disappointed on that front up to this point.

I guess as I ponder this issue, I am struggling to see which critical
section primitives should be provided as "base GCC+avr-libc" independent of
any OS, and which should be provided by an OS on top of the basic toolset.
Do you have any ideas for guidelines we can use to choose which ones belong
in each category?

Perplexed,
Scott


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
David Brown
Sent: Sunday, May 25, 2008 3:00 PM
To: address@hidden
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

Graham Davies wrote:
> David Brown wrote:
>> ... you are ... protecting the code sequence, not the data itself - 
>> the data is indirectly protected by always using
>> protected code sequences to access it.
> 
> I think this is just a point-of-view thing.  I could be wrong, but I 
> think the prevalent point of view is that it is the data that needs to 
> be protected.  Any means to do that would be acceptable.  It seems 
> strange to talk about protecting the code sequence.  Making sure that 
> the code executes in sequence and without interruption is just a means 
> to the primary end of protecting the data.
> 
> Graham.
> 

In some cases, it makes sense to think about protecting the data - in 
particular, you often want to make sure that no part of the program can 
access the data in an inconsistent state.  In that sense, you protect 
code sequences as a way to protect the data.  But you also want 
sequences of code that access different data objects rather than 
directly protecting the data.

Ultimately, code is merely something that manipulates data, and data is 
merely intermediate results of code, so it is, as you say, a 
point-of-view thing.  My point was just that it is often most practical 
to think in terms of protecting code sequences rather than data - you 
can't view all cases in terms of protecting data until you abstract to 
the level of all the data in the system being part of a single large 
object, and all the code in the system being methods manipulating that 
data object.

At least, that's how I view it.  Perhaps if I were a C++ programmer 
rather than a C programmer, I'd view it in a more data-centric way.


mvh.,

David




_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 269.24.1/1464 - Release Date: 5/24/2008
8:56 AM
 





reply via email to

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