[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Should cli() imply a memory barrier?
From: |
Paulo Marques |
Subject: |
Re: [avr-libc-dev] Should cli() imply a memory barrier? |
Date: |
Tue, 08 Jun 2010 20:23:23 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
Bob Paddock wrote:
>> This raises the question: Some years ago, a discussion about whether
>> cli() should include a memory barrier ended with an agreement that
>> it's not needed.
>
> cli() should produce code of "least surprise". Most people are
> surprised when they find their explicitly placed cli() has been
> (re)moved by code reordering.
> atomic.h should be mentioned if the documentation route is the one
> chosen. Seems like there is some overlap here?
I agree with the "least surprise" argument, and that we should mention
atomic.h in the documentation.
One thing we could do for the programmers that want to use the "raw" cli
version and know what they are doing is to keep a "__cli" or "__raw_cli"
version (or some other name) that just emits a single "cli" instruction.
--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com
"Who is general Failure and why is he reading my disk?"
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Jan Waclawek, 2010/06/08
- RE: [avr-libc-dev] Should cli() imply a memory barrier?, Weddington, Eric, 2010/06/08
- Re: [avr-libc-dev] Should cli() imply a memory barrier?, Joerg Wunsch, 2010/06/09