MSP430-GCC-OPENSOURCE: Errors in GCC?

I should probably have mentioned the assembler version:

GNU assembler (Mitto Systems Limited - msp430-gcc 9.2.0.50) 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,

-George

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:

MEMORY
{
    ROM (rx):          ORIGIN = 0xfc00, LENGTH = 1020
    RESET_VECTOR (r):  ORIGIN = 0xfffe, LENGTH = 2
}

SECTIONS
{
    .text :
    {
    } > ROM

    reset_vector :
    {
        SHORT(reset)
    } > RESET_VECTOR
}

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

Cheers,

John

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,

-George

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.

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.

Regards,