waitvid in waitcnt

Comments

• Kye Posts: 2,200

  2012-03-27 15:23 edited 2012-03-27 15:23

  Its not waitvid, its -3932 in hex. The disassembler does not know the difference between code and data.
  
  When you see the "jmp e8 <__LMM_MVI_xx>" this means whatever that is next is data.
  
  Maybe a fix in the future could be applied to the dissembler to make the output more readable?
• Kye Posts: 2,200

  2012-03-27 15:30 edited 2012-03-27 15:30

  Here's a good question... why does the code generator allocate a MOV immediate value of zero in the code space??? There is no reason not to just use the mov reg, #0 form. There is no need for an immediate value expression.
• denominator Posts: 242

  2012-03-27 16:09 edited 2012-03-27 16:09

  Kye wrote: »

  Here's a good question... why does the code generator allocate a MOV immediate value of zero in the code space??? There is no reason not to just use the mov reg, #0 form. There is no need for an immediate value expression.

  
  The answer becomes apparent if you look at the assembly generated by compiling the delay_msec function with the "-Os --save-temps" flags:
  

  _delay_msec
          mov     r7, CNT
          jmp     #__LMM_MVI_r5
          long    -3932
          add     r7, r5
          jmp     #__LMM_MVI_r5
          long    __clkfreq
          mov     r6, r0
          jmp     #__LMM_MVI_r1
          long    1000
          rdlong  r0, r5
          call    #__UDIVSI
          mov     r1, r0
          mov     r0, r6
          call    #__MULSI
          add     r7, r0
          waitcnt r7,#0
          mov     pc,lr
  

  
  The disassmbler's lack of the original symbol table obscured the actual intent.
• Kye Posts: 2,200

  2012-03-27 16:51 edited 2012-03-27 16:51

  Ah, yes, its a lot easier to read now.
  
  Thanks, denominator!
• d2rk Posts: 31

  2012-03-28 02:35 edited 2012-03-28 02:35

  Thanks, Kye and denominator.