OK, the changes to GAS parsing is done. I think this should make it easier to find problems. So here's a test file with lots of errors:

    eric@compaq:~/dev/tios/src/gas_test$ cat gastest.asm
        mov r1
        mov r1+,r2
        mov r1,r2+
        inv r1, r2
        inv r

And here's the result from the new parsing code:

    eric@compaq:~/dev/tios/src/gas_test$ tms9900-gas gastest.asm
    gastest.asm: Assembler messages:
    gastest.asm:1: Error: unexpected end of line
    gastest.asm:2: Error: unexpected character at "+,r2"
    gastest.asm:3: Error: unexpected character at "+"
    gastest.asm:4: Error: unexpected character at ",r2"
    Invalid register starting at "r"
    gastest.asm:5: Error: missing argument

Could this be better? Maybe, but it's a lot better than before. Time to get back to floating point code.

I've been slacking off keeping this up to date. Lately I've been working on floating point support for GCC. I've got float-to-int and int-to-float working, and I'm trying to get addition working.

While working on that I found more annoying error messages in GAS. This line:

    mov r10+, r11

gives this error:

    test.asm:381: Error: missing comma separator

This is not helpful, especially since there is a comma in the expected location. What's really wrong is the missing "*" character. Unfortunately, We cannot make GAS smart enough to recognize that. We could look for junk after the last expected character, but we can't do that either since the TI format allows for junk at the end of the line. We could look for white space and do something smart, but GAS squeezes that out before our code is called.

Unfortunately, the best we can do is flag the error with as much information as we can. This is more descriptive and shows what the real problem is.

    test.asm:381: Error: unexpected character at "+,r11"

Another problem I have, but cannot fix without violating TI comment rules, is if we get lines like this:

    mov r11, r10+
    inv r1, r2, r3

The trailing invalid characters are ignored, no error will be emitted, and the assembled instructions will actually be this:

    mov r11, r10
    inv r1

This is totally unexpected behaviour, and confusion and anger may follow.