Using uvision4 to build project for Cortex-M3. When I look at assembly listing I notice that the __schedule_barrier() call generates two NOPs instead of using one of the ARM memory barrier instructions. Is this correct?
Thanks
Thanks for responding Scott.
From the Keil documentation from __schedule_intrinsic():
"This intrinsic creates a sequence point where operations before and operations after the sequence point are not merged by the compiler. A scheduling barrier does not cause memory to be updated. If variables are held in registers they are updated in place, and not written out.
This intrinsic is similar to the __nop intrinsic, except that no NOP instruction is generated."
I was assuming that an ARM memory barrier instruction would be generated but instead two NOPs are generated.
My intent was to ensure that pending interrupts were cleared prior to exiting an ISR, e.g. in order to prevent an issue where I popped right back into the ISR but the pending interrupt bits were cleared (apparently somewhere between the return from the ISR and the reentry).
isr() {
... ...
clearpendingbits()
_schedule_intrinsic()
}
In any case, I have found a way to get around the issue without the __schedule_intrinsic() call but was wondering why it was implemented as such at least by the tools I am using.
The __force_stores(), __memory_changed() and __schedule_barrier() intrinsics only effect the compiler's view of the world. Somewhat suprisingly they don't generate any barrier instructions.
I also happend to notice these related Knowledge Articles:
- In what situations might I need to insert memory barrier instructions? <infocenter.arm.com/.../ka14041.html>
- Does Cortex-M3 need Memory Barrier instructions? <infocenter.arm.com/.../ka13593.html>
- Why are barrier instrinsics not documented in the compiler documentation? <infocenter.arm.com/.../ka14552.html>
Hi Scott,
Somewhat more surprising is the fact that a memory barrier intrinsic does not imply a preceeding __force_stores() behavior. In a particular case, the compiler scheduled the critical memory access after the the memory barrier rendering the latter practically useless. This may have changed since I raised a support case about this although I was told back then that there were valid use cases for the observed behavior (w/o giving an example).
Regards Marcus http://www.doulos.com/arm/