• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 22 subscribers
  • Views 1890 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

__schedule_barrier function creates NOPs

A Shepard

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

Parents
  • 0 in reply to Scott Douglass

    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/

Reply
  • 0 in reply to Scott Douglass

    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/

Children
No data