In increasing order of difficulty, in your position I would do:
1) The solution mentioned before and made explicit below, which is not
optimal but does appear to meet your stated requirements for
atomicity;
2) Redesign my firmware (assuming it's under 100KLOC);
3) Modify mspgcc to add intrinsics that support atomic operations.
Peter
llc[26]$ cat /tmp/x.c
#define DIRTY_FLAG 0x1
volatile int state;
void doit () {
volatile int tmp = (state >> 1) & DIRTY_FLAG;
state |= tmp;
}
llc[27]$ /msp430/install/lts-20120406-20120502/bin/msp430-gcc -Os -S /tmp/x.c
llc[28]$ cat x.s
.file "x.c"
.cpu 430
.mpy none
.text
.p2align 1,0
.global doit
.type doit,@function
/***********************
* Function `doit'
***********************/
doit:
sub #2, r1
mov &state, r15
rra r15
and #1, r15
mov r15, @r1
bis @r1, &state
add #2, r1
ret
.Lfe1:
.size doit,.Lfe1-doit
;; End of function
.comm state,2,2
llc[29]$
On Sun, Sep 2, 2012 at 2:38 PM, William Swanson <swanson...@gmail.com> wrote:
> On Sun, Sep 2, 2012 at 4:05 AM, David Brown <david.br...@hesbynett.no> wrote:
>> I think the nearest you could get would be to implement built_in
>> functions such as __built_in_bis(dst, src) for an atomic "|=".
>
> This is exactly the right thing. It's pretty common to do code like this:
>
> flags |= (a bunch of code);
>
> The goal is to set a bit in the shared flags register. If an ISR tries
> to toggle other bits at the same time, those changes would be
> clobbered unless the "|=" operator is atomic. The stuff on the right
> doesn't write to the shared location, so it does not need to be
> atomic.
>
> My original example contained a red herring, in that it also read from
> the shared location:
>
> state |= (state >> 1) & DIRTY_FLAG;
>
> However, as I said before, I do *NOT* expect the right-hand side to be
> atomic. Only the "|=" operator needs to be atomic. This particular
> example is copying the to the left of DIRTY_FLAG into DIRTY_FLAG. The
> bit to the left is stable at this particular point in time, so there
> is no need to treat it specially.
>
> Therefore, the following code expresses the intent perfectly:
>
> U8 temp = (state >> 1) & DIRTY_FLAG;
> __atomic_bis(state, temp);
>
> Since we don't have __atomic_bis or anything like it, I have been
> combing through my codebase and eliminating anything like this. I'm
> only about half done.
>
> On Sun, Sep 2, 2012 at 6:43 AM, Przemek Klosowski
> <przemek.klosow...@gmail.com> wrote:
>> It seems to me that a better approach is to admit the reality that
>> it's a hardware specific operation, and express it via the appropriate
>> asm(), perhaps with some syntactic sugar of function/library calls.
>
> Inline assembly blocks interact poorly with the surrounding C code, so
> the atomic primitives really need to be intrinsic functions.
>
> Atomic intrinsics are pretty common, even if they are
> hardware-dependent. GCC has them on other targets, the Microsoft
> compiler has them, Glib has them, and the C++11 actually bakes them
> right into the standard library. It's weird that mspgcc doesn't have
> them, although I understand that our noble maintainer has enough on
> his plate as it is.
>
> I wonder if it would be a more efficient use of my time to just add
> __atomic_bis to the compiler myself, rather than re-design my entire
> firmware.
>
> -William
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
