• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 4835 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

CM3 / RVDS / NOPs

David Clark
Parents
  • Note: This was originally posted on 15th June 2010 at http://forums.arm.com

    I guess the loop structure:
      do { __disable_irq(); } while (0)
    might have cause the NOPs.
    Although it didn't expand into a loop, the compiler might have reserved the space for instructions if a loop is needed.
    And because it is -O0, it didn't remove the unused instruction space and hence NOPs is used.


    Hi Joseph,

    Thanks for the reply.  Yeah, I guess the [font="Courier New"]do {} while()[/font] construct caused the NOPs, since that is the noticeable difference in the source, but even then, their presence is puzzling.  I suppose I could try putting something other than PRIMASK manipulation in the statement, something like incrementing a counter or whatever, and seeing if the NOPs are still generated, but for now it's "case closed".

    Maybe the -O1 optimization level should be my baseline level -- seems like there is probably still good debugging visibility.

    Again, many thanks for the time & replies.
Reply
  • Note: This was originally posted on 15th June 2010 at http://forums.arm.com

    I guess the loop structure:
      do { __disable_irq(); } while (0)
    might have cause the NOPs.
    Although it didn't expand into a loop, the compiler might have reserved the space for instructions if a loop is needed.
    And because it is -O0, it didn't remove the unused instruction space and hence NOPs is used.


    Hi Joseph,

    Thanks for the reply.  Yeah, I guess the [font="Courier New"]do {} while()[/font] construct caused the NOPs, since that is the noticeable difference in the source, but even then, their presence is puzzling.  I suppose I could try putting something other than PRIMASK manipulation in the statement, something like incrementing a counter or whatever, and seeing if the NOPs are still generated, but for now it's "case closed".

    Maybe the -O1 optimization level should be my baseline level -- seems like there is probably still good debugging visibility.

    Again, many thanks for the time & replies.
Children
No data