LeafLabs Garden » Topic: cli() and sei() for Maple 5

LeafLabs Garden » Topic: cli() and sei() for Maple 5 http://forums.leaflabs.com/topic.php?id=2617 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:07 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php mbolivar on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13077 Sun, 02 Sep 2012 00:34:07 +0000 mbolivar 13077@http://forums.leaflabs.com/ heh, that's definitely one way of going about it. throwing in every fence available on the architecture is the definitely thermonuclear option, though. i suppose that's the safest thing to do given that we haven't heard any feedback on the semantics of the memory barriers implied by cli()/sei(). x893 on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13040 Sat, 01 Sep 2012 03:06:11 +0000 x893 13040@http://forums.leaflabs.com/ If i add <pre><code>static inline void __ISB() { __asm volatile ("isb"); } static inline void __DSB() { __asm volatile ("dsb"); } static inline void __DMB() { __asm volatile ("dmb"); }</code></pre> and modify <pre><code>void CriticalSectionEnter(void) { if (CriticalSectionCount == 0) { __disable_irq(); __DMB(); __DSB(); __ISB(); } CriticalSectionCount++; }</code></pre> ? mbolivar on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13033 Fri, 31 Aug 2012 19:05:19 +0000 mbolivar 13033@http://forums.leaflabs.com/ x893, <blockquote> this not work ? </blockquote> no; that enables/disables interrupts, but neither implies a memory barrier. so it might work like cli()/sei() in some situations, but not others. please read my above message in this thread discussing cli()/sei() and memory barriers: <a href="http://forums.leaflabs.com/topic.php?id=2617#post-13004" rel="nofollow">http://forums.leaflabs.com/topic.php?id=2617#post-13004</a> x893 on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13031 Fri, 31 Aug 2012 18:34:44 +0000 x893 13031@http://forums.leaflabs.com/ For atomic i use very simple construction (thread safe) volatile uint32_t CriticalSectionCount = 0; void CriticalSectionEnter(void) { if (CriticalSectionCount++ == 0) __disable_irq(); } void CriticalSectionExit(void) { if (--CriticalSectionCount == 0) __enable_irq(); } and in code ... CriticalSectionEnter(); // execute with disable irq, also can call other critical codes CriticalSectionExit(); x893 on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13030 Fri, 31 Aug 2012 18:28:13 +0000 x893 13030@http://forums.leaflabs.com/ I see core_cm3.h from ST library and see next static inline void __enable_irq() { __asm volatile ("cpsie i"); } static inline void __disable_irq() { __asm volatile ("cpsid i"); } this not work ? mbolivar on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13027 Fri, 31 Aug 2012 15:49:16 +0000 mbolivar 13027@http://forums.leaflabs.com/ <blockquote> FWIW, the version of the port I am currently testing compiles and assembles without complaint </blockquote> Just because it builds doesn't mean the memory ordering constraints it implies are the same. If this is going to go into the core library, it's important to get those right. <blockquote> Perhaps a "belts and braces" way to implement a memory barrier/execution order safe cli() would be something like this: __asm__ volatile ("CPSID i\n\t""dmb\n\t" ::: "memory") </blockquote> That seems pretty reasonable. Are you confident that <code>dmb</code> provides the same semantics as cli() (versus <code>dsb</code>, etc.)? The AVR docs for cli() are a little underspecified for my taste. Next question -- where should these go? I was thinking of adding a Wirish-level avr_compat.h header for things like this. People can then include it as a quick-and-dirty mechanism when porting code. Seem reasonable? By the way, <a href="http://leaflabs.com/docs/lang/api/nointerrupts.html#lang-nointerrupts">noInterrupts()</a> and <a href="http://leaflabs.com/docs/lang/api/interrupts.html#lang-interrupts">interrupts()</a> should both compile down to the single machine instruction they imply (<code>cpsid i</code>/<code>cpsie i</code>), so it's nice to use them instead of assembly for readability. pico on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13026 Fri, 31 Aug 2012 12:10:57 +0000 pico 13026@http://forums.leaflabs.com/ Having read a little more about "memory barriers", I see that there are _CPU_ memory barrier instructions to conttrol out-of-sequence execution of instructions due to e.g., pipelining, and there are also _compiler_ memory barrier directives, such as the "":::"memory" directive GCC uses to control reording due to optimisations. Perhaps a "belts and braces" way to implement a memory barrier/execution order safe cli() would be something like this: <code> __asm__ volatile ("CPSID i\n\t""dmb\n\t" ::: "memory") </code> What do you think? pico on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13021 Fri, 31 Aug 2012 01:44:00 +0000 pico 13021@http://forums.leaflabs.com/ Not sure if talking about exactly the same thing, but I've started porting over the ATOMIC_BLOCK macros to see if I can get equivalents working under ARM, and I've come across this construct: <code> static __inline__ void __iRestore(const uint32_t *__s) \ { __set_primask(*__s); __asm__ volatile ("" ::: "memory"); } </code> where the asm "memory" directive is in the "clobber list" position in an otherwise empty line of assembly code, which I understand constrains any reordering optimisations at that point the compiler might otherwise consider. Along with "volatile", these are directives that basically close off optimisations to prevent these instruction being moved to unexpected places. Is this what you mean by a "memory barrier"? FWIW, the version of the port I am currently testing compiles and assembles without complaint with these directives, so perhaps there is nothing going on that isn't portable across the AVR and ARM versions of GCC. mbolivar on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-13004 Thu, 30 Aug 2012 14:48:56 +0000 mbolivar 13004@http://forums.leaflabs.com/ I've thought about doing something like that. The only part I worry about is that apparently cli()/sei() imply memory barriers: <a href="http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#ga68c330e94fe121eba993e5a5973c3162" rel="nofollow">http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#ga68c330e94fe121eba993e5a5973c3162</a> To faithfully emulate them, then, we'd need to do the same thing. I'm not sure which of the <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211i/Babfdddg.html">ARM memory barriers</a> is equivalent to the AVR version. Can anyone provide some advice here? pico on "cli() and sei() for Maple 5" http://forums.leaflabs.com/topic.php?id=2617#post-12983 Wed, 29 Aug 2012 10:14:51 +0000 pico 12983@http://forums.leaflabs.com/ After some reading, I found the asm instructions to disable/enable interrupts by setting PRIMASK for the Cortex-M3, so I'm assuming this should work for a Maple 5: <code> #define _cli asm("CPSID i\n\t") #define _sei asm("CPSIE i\n\t") </code> Any reason why this might be problematic? Any reason why they weren't included in the libs for greater compatibility with Arduino code? FWIW, they seem to be compiling and working as expected so far in my programs I'm porting to Maple 5 from AVR Arduino. But thought I'd ask in case I'm missing something basic (or even not so basic) here...