• Locked Locked
  • Replies 9 replies
  • Subscribers 120 subscribers
  • Views 4644 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

CM3 / RVDS / NOPs

David Clark
  • Arm Employee Badge
    Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    Hi Wave,

    I cannot reproduce the problem. For example, I use the following C code:
      UartStdOutInit();
      __disable_irq();
      printf("Hello world\n");
      __enable_irq();
      UartPutc((char) 0x4);

    The disassembly result is:
            0x00000166:    f000f849    ..I.    BL       UartStdOutInit ; 0x1fc
            0x0000016a:    b672        r.      CPSID    i
            0x0000016c:    a003        ..      ADR      r0,{pc}+0x10 ; 0x17c
            0x0000016e:    f000f86d    ..m.    BL       __2printf ; 0x24c
            0x00000172:    b662        b.      CPSIE    i
            0x00000174:    2004        .       MOVS     r0,#4
            0x00000176:    f000f84c    ..L.    BL       UartPutc ; 0x212

    I used ARM RVDS 4.0-SP3,
        ARM C/C++ Compiler, RVCT4.0 [Build 650]
        ARM Assembler, RVCT4.0 [Build 650]
        ARM Linker, RVCT4.0 [Build 650]

    armcc option : -c -O0 -W -g -Otime --cpu Cortex-M3

    Could you generate a test case? Thanks
    regards,
    Joseph
  • Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    I'm wondering why RVDS insists on inserting so many NOPs into the generated code.[font="Courier New"]
    ;;;177        ENTER_CRIT();
    [/font]

    Please check out the definition of the above macro(?). I am sure these NOPs get generated explicitly.

    Regards
    Marcus
  • Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    Please check out the definition of the above macro(?). I am sure these NOPs get generated explicitly.

    Regards
    Marcus


    Hi Marcus,

    Thanks for your reply.  Actually, the macro just expands to  __disable_irq()

    I should have included that information initially.  There are other examples of what seem to be lots of NOPs, some that have nothing to do w/ interrupts, I'll put in another example below.

    Hi Joseph,

    Thanks for your reply.  I'll follow up w/ a post on my configuration, I suspect it's similar if not identical, but I'll get the toolset config & post back.

    It's interesting that the __disable_irq() intrinsic didn't generate the NOPs for you.  I suppose a cut & paste of my compiler command line would probably also be useful.

    I'll post back with a) the toolset config, B) the compiler command line, and c) another example that has lots of NOPs that doesn't manipulate interrupts at all.  I realize it's very difficult to troubleshoot / understand / explain a compiler's behavior without the full picture, it's just that right now I'm not at liberty to paste in full chunks of source code.  I'll try to create a standalone mini-test case, that would probably get us the most useful information right away.

    Thanks to you both, back soon.
  • Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    Sorry for the fragmented reply.

    Regarding the toolset configuration, it looks like:

    RVDS 4.0.3, build  140 (from Eclipse Help->About ARM Workbench)
    Eclipse C/C++ Development tools 4.0.3.200807100946
    Another help page says RVDS v4.0 Professional  4.0.0.408

    I'm wondering if this is a pretty old toolset rev.  It's a full license (one of several actually), but it looks from the info above to be a bit out of date.  Under Eclipse, when I tell it to look for software updates, it says everything is up to date.  Hmmm.  Maybe I need to talk w/ the tools / licensing group.

    Compiler command line:
    armcc -c --diag_style=ide --depend_format=unix_escaped --no_depend_system_headers --debug --cpu=Cortex-M3 -O0 --no_inline --force_new_nothrow --asm --interleave -ofile.o file.c

    I'll still generate a full test case & come back & post, but please let me know if this toolset is far & away from the latest & greatest, that might explain a lot.

    Thanks again for the help -- helping people with stuff like this is pretty unfun & painful.
  • Arm Employee Badge
    Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    Please try switch from -O0 to -O1, or -O2, and see if it remove the NOPs.
  • Note: This was originally posted on 14th June 2010 at http://forums.arm.com

    Please try switch from -O0 to -O1, or -O2, and see if it remove the NOPs.


    Hi Joseph,

    Yep, even switching to -O1 did the trick.  NOPs are gone, plus a few other small things changed.

    Do you know why the lowest optimization level would have the NOPs?  They just seem so unnecessary & wasteful, I can't imagine why they're there even with optimization disabled.  It seems like the compiler went out of its way to put them there.  The output with -O1 (from a quick diff of the 2 generated assembly listings) is closer to what I'd have expected with optimization disabled.  It's almost like -O0 = "fluff up the code".

    Sorry, I don't expect/want you to apologize/defend/explain the compiler, I'm sure there are reasons, they're just not obvious to me.

    Thanks for your input on the issue, too.

    By the way, I'm going to install the latest version of the RVDS tools, maybe that alone will rectify the -O0 output... will post back.
  • Arm Employee Badge
    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.
  • 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.