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.



The MSP430 as a nice example of a simple and clean instruction set, I used it in my classes to show how to create a disassembler. To test the disassembler, I wrote a some assembler code to generate a binary file, and found some strange issues:

    swpb.b  r5     ; Accepted without warning by the assembler, and even the B/W bit is set accordingly, even though
                   ; in most instruction set tables that bit shown to be 0 and .b doesn't make sense. And what does the hardware do?

    sxt.b   r6     ; Same problem

    rrc     0(r0)  ; Generates: Error: rrc: attempt to rotate the PC register
                   ; though I understand that 0(r0) actually points to the word following the opcode, not the register
                   ; so this would be akin to self-modifying code, but:
    rrc     2(r0)  ; is accepted without issue, which is only marginally better

Am I wrong here?

  • I should probably have mentioned the assembler version:

    GNU assembler (Mitto Systems Limited - msp430-gcc 2.34
    Copyright (C) 2020 Free Software Foundation, Inc.

  • Even  "call.b r5" is accepted! (and the B/W bit set to 1)

  • Please show exactly how the assembler is invoked.  Please copy-and-paste the text of the full command, and do not use a screen shot.

    Thanks and regards,


  • When I tried "swpb.b r6" as a test case, gas accepted it without warning but objdump renders it as ".word 0x10c6".

    As for what swpb.b (0x10c6) does, in my tests it does not swap the bytes. It may do other things but it doesn't do that.

    But anyone writing swpb.b expecting something useful has other problems.

  • Hello George.

    I made a Makefile like this:

    test.hex: test.asm
    	msp430-elf-as -o test.obj test.asm -al=test.lst
    	msp430-elf-ld -T test.cmd -o test.out test.obj
    	objcopy -O ihex test.out test.hex

    And a simplistic command file for the linker:

        ROM (rx):          ORIGIN = 0xfc00, LENGTH = 1020
        RESET_VECTOR (r):  ORIGIN = 0xfffe, LENGTH = 2
        .text :
        } > ROM
        reset_vector :
        } > RESET_VECTOR

    BTW, I also noted that CALL.B is accepted, which doesn't make any sense.



  • Thanks for the tests, David.

    Yes, 0x10C6 has the B(yte) flag set (bit 6).

    > But anyone writing swpb.b expecting something useful has other problems.

    Maybe, but I'd expect an assembler to syntax check more thoroughly. Even though probably 99% of users just us gas for C post-processing.

    Also, if an error would pop on 'swpb.b', 'reti.b', 'call.b' and 'sxt.b', it would warn the user to a problem before requiring debugging.

  • gas is just a back end for gcc. Using it standalone is tricky. Several years ago they made a change which broke my code and required some work to find a new way to do the same thing. Which could break again if the gcc maintainers decide it would make life easier for gcc.

  • I tried your test case with both the TI and GCC assemblers.  They do not act the same way.  I'm not sure which is right or wrong.  So, I filed the issue EXT_EP-10081 against the TI assembler.  Depending on what happens there, we may file another issue against the GCC assembler.  You are welcome to follow the issue with the link below in my signature.

    With regard to invoking the GCC assembler directly ... I never do that.  I'm pretty sure it is common practice to invoke msp430-elf-gcc (or whatever variant of GCC is being used), then it processes the file as needed, based on the file extension.  The extension .s means an assembly file.  For more details, please see the Options Controlling the Kind of Output from the GCC online documentation.

    Thanks and regards,


  • I like to use gcc rather than gas on its own because it will run an assembly language file with extension ".S" (capitol S) through the preprocessor first. So I can include the device header file with all of those handy special function register definitions.

  • To understand why this thread is considered resolved, please see the first FAQ in the CCS Forum Usage Guidelines.

    Thanks and regards,


  • I would agree that the assembler should be syntax checking more thoroughly. Even though some of these tests are contrived, they should be easy for the assembler to spot and warn about.

    Given that MSP430 is a nice, simple instruction set, it is probably not too uncommon for people to write assembly code and invoke GAS directly.

    We'll aim to improve the assembler syntax checking in a future release of MSP430-GCC.


**Attention** This is a public forum