On Fri, Aug 24, 2012 at 12:50 PM, William Swanson <swanson...@gmail.com> wrote: > On Fri, Aug 24, 2012 at 8:24 AM, Grant Edwards > <grant.b.edwa...@gmail.com> wrote: >> IIRC, some of the early processors had bugs in the "special case" >> handling for the BIC instruction, and clearing interupt flags in some >> registers _didn't_ work reliably. > > That's good to hear, since it means TI has dealt with this issue in > the newer chips. Clearing an interrupt flag with a single "bis" > instruction is probably safe on a hardware level. If not, the chip > would be "pretty broken" as you put it.
In fact there remain a large number of chip errata that could theoretically cause problems, but most of them involve manipulations of the program counter or stack register that would never occur in compiler-generated code. > On Fri, Aug 24, 2012 at 2:08 AM, David Brown <da...@westcontrol.com> wrote: >> There is no guarantee that the compiler will produce a single "bis" >> instruction for such code (though it normally will) - as I said before, >> "volatile" gives you very few guarantees according to the standards. > > I've been doing some tests, and it looks like the msp430 GCC compiler > will only emit a single "bis" instruction when the value on the right > is a constant. If it's a variable expression, GCC will fall back on an > explicit read/modify/write sequence. That's not entirely accurate, but is a good first approximation. In fact mspgcc currently relies on gcc's middle-end processing for volatile management, which does do explicit multiple reads and writes as specified by the ISO standard. It is only in the peephole optimization phase for the MSP430 back end that certain instruction sequences can be recognized and replaced by single read-modify-write instructions and therefore made atomic. Those optimizations try to be conservative, though in fact I recently discovered an error in them that will be fixed when I get back to mspgcc in a couple weeks. Peter > Since we are targeting the GCC compiler pretty explicitly, I think we > can just rely on this behavior and move on. If the "&=" is good enough > for the TI code examples, it should be good enough for us. > > -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
