• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 1670 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430-elf-objcopy disassembly issue

Krista Hill
Prodigy 70 points
Other Parts Discussed in Thread: MSP430G2231

Hi folks;

I'm practicing my MSP430 assembly language skills and came across something I'm not sure of.

In a program I tried the following to test the value in r6.

     cmp     r6,#0x00

When I use objdump with the -d option, it produces a simple disassembly.

The disassembly from objdump includes the following:

    f816:       03 96           .word   0x9603; ????

In looking at references the instruction appears to be encoded correctly, also the program simulated correctly with msp430-elf-gdb. It's just that objdump was not able to properly decode the instruction. The processor is the MSP430G2231

The situation is strange as a few instructions later another compare instruction is properly handled

    f81a:       06 95           cmp     r5,     r6

Please take a look into objdump. I inserted the program source below.
Much thanks in advance;

; main.S - ex06 - Dec. 2, 2015
         .file "main.S"
#include "asminc.h"

         .data
RamAdx:  .fill   1

         .text
_start:  mov.w   #WDTPW|WDTHOLD,&WDTCTL
         mov.w   #__stack,SP
         mov.w   #List,r4
         clr     r5
top:     mov.b   @r4,r6
         cmp     r6,#0x00
         jeq     done
         cmp     r5,r6
         jlo     pass
         mov     r6,r5
pass:    inc     r4
         jmp     top

done:    jmp     done

List:    .byte    0x12,0x24,0x18,0x43,0x16,0x00

         .section ".resetvec","ax",@progbits
         .word    _start

 

  • 0
    Prodigy 70 points
    ; asminc.h
    #include <msp430.h>

    #define PC r0
    #define SP r1
    #define SR r2
    #define CG1 r2
    #define CG2 r3
  • 0 in reply to Krista Hill
    TI__Guru**** 244930 points

    Thanks for reporting the problem.  I notified the msp430 GCC tools experts at Red Hat.

    Thanks and regards,

    -George

  • 0
    Intellectual 390 points
    Try "cmp #0x00,r6" instead - the msp430 disassembler is very generic and doesn't support constants as the destination operand (i.e. "add r6,#0x00" uses the same logic). The examples in the TI documentation for CMP also list the constant first.
  • 0 in reply to George Mock
    Prodigy 70 points

    Thanks much;

    Krista

  • 0 in reply to DJ Delorie
    Prodigy 70 points
    Thanks much for clarifying that point, I see the logic.
  • 0 in reply to Krista Hill
    Prodigy 70 points

    Just gave it a try, your fix does work.

    Krista

  • 0 in reply to Krista Hill
    Prodigy 70 points
    Hold it for a moment, just looked at the instruction set again and see only 8 conditional jump instructions. How can that be? If you remove jump-equal, jump-not equal, and jump-always, that leaves only 5 other conditional jumps.

    o There is jump-lower than, jump-higher-or-same, but no jump-higher, and no jump-lower-or-same
    o There is a jump-negative, but no jump-positive
    o There is jump if greater-or-equal, jump-less-than, but no jump-less-than-or-equal, and no jump greater-than

    Of course, to achieve a complement conditional test, it is enough to swap the operands when performing the comparison.
    With the above observation in mind, I would think that being able to use the second operand for constant values is a necessary part of the instruction set. I would think that compare is most certainly an important exception.
  • 0 in reply to Krista Hill
    TI__Guru* 84225 points

    It's not strictly necessary. Typically you just adjust the constant:

        CMP #1, R12
    JGE case_not_le_zero
    MOV #2, R13 ; if (R12 <= 0) ...
case_not_le_zero: