On 2012-08-23, William Swanson <swanson...@gmail.com> wrote:
> On Thu, Aug 23, 2012 at 12:49 PM, William Swanson <swanson...@gmail.com>
> wrote:
>>> Another option is a single inline assembly call for the "|=" if the above
>>> code split does not help.
>>
>> I've had to do this in a few places, like when I need to atomically
>> update a hardware flag.
>
> I just realized something horrible. Code like this is not safe:
>
> P1IFG &= ~P1_PWR_SW;
Indeed. The C language definition does not guarantee that is an atomic
operation.
However, in the real world, what one tends to do is verify that such a
statement _does_ produce an atomic operation using a particular
version of a particular compiler, and then one goes ahead and uses
that construct.
You just have to remember to re-verify your assumptions every time you
change/update the compiler.
> There is no assurance that the "&=" operator will work atomically.
> Even if it does compile to the correct "bis.b" instruction, what
> happens if another IO pin toggles mid-instruction?
Are you asking specifically about the IFG registers? I think they're
probably handled as a special case by the hardware to avoid such a
problem.
> Could the transition be lost?
One has to assume not. A processor with no way to clear an interrupt
flag would be pretty broken.
> Hopefully the chip designers accounted for this, but it's still a
> scary thought.
On many processors doing things like clearing an interrupt flag is
done by writing a 1 to the bit you wish to clear. That makes the
hardware implementation much simpler and it lets you use a C statement
like:
P1IFG = P1_PWR_SW;
Which is much less likely to be a non-atomic operation.
--
Grant Edwards grant.b.edwards Yow! I'm ANN LANDERS!!
at I can SHOPLIFT!!
gmail.com
------------------------------------------------------------------------------
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
