• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1617 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5359: Are the instruction opcodes 10C0 through 10FF and 11C0 through 11CF truly reserved?

Atlant Schmidt
Expert 1715 points
Part Number: MSP430F5359

Folks:

In SLAU208Q (June 2008–Revised March 2018), the MSP430x5xx and MSP430x6xx Family User's Guide, Table 6-20 indicates that instruction opcodes in the regions 10C0 through 10FF and 11C0 through 11CF are all reserved. See below.

These two code spaces are where the SWPB.B and SXT.B instructions could live but these instructions are essentially meaningless.

Oddly enough, as long as you specify them using the "X" (MSP430 "Extended" architecture) style, the IAR icc430 C Compiler (in its latest released version) accepts those instruction mnemonics and generates the expected opcodes in those two regions:

I ASSUME that those instructions won't actually be decoded and correctly executed by the various MSP430X processors. Is that assumption correct? What will the processors actually do if handed this code?

And if my first assumption is correct, then I further ASSUME that this is a bug in the IAR compiler/assembler and I ought to report it to IAR?

Atlant

  • 0
    Guru 316880 points
    These opcodes are not defined by TI. You could test what they do in the chip you have in front of you, but there is no guarantee that any other chip, or even a future version of the same chip, behaves the same.

    I do not know if IAR accepting an invalid opcode combination is considered a bug. It could be said that assembler programmers are supposed to know what they're doing.
  • 0 in reply to Clemens Ladisch
    Expert 1715 points
    Clemens:

    > These opcodes are not defined by TI. You could test what they do in the
    > chip you have in front of you, but there is no guarantee that any other chip,
    > or even a future version of the same chip, behaves the same.

    Believe me: I used to develop PDP-11, VAX-11, and Alpha processors for Digital Equipment Corporation (DEC) so I know better than to try and use a truly reserved opcode ;-). Even from one product mask stepping to the next, there's no guarantee that the behavior will be consistent.

    > I do not know if IAR accepting an invalid opcode combination is considered
    > a bug. It could be said that assembler programmers are supposed to know
    > what they're doing.

    Generally speaking, the IAR assembler seems pretty good at flagging illegal operations although the specific diagnostics it emits are sometimes not the most helpful. If we all end up agreeing that this opcode range really is reserved, I'll definitely try filing a bug report with IAR.

    Atlant
  • 0 in reply to Atlant Schmidt
    TI__Genius 17960 points
    Hi Atlant,
    these opcodes are really reserved. Executing a SWPBX is not really meaningful in the original sense of a swap byte, as the "X" expansion is related to the 20bit format, while the memory architecture is 16bit wide. Thus while swapping high and low byte makes sense with 16bit, 20bit would require some kind of "workaround". IF you really want to spend time on this, please check with IAR, what their intention in this case is. Many thanks in advance.

    Best regards
    Peter
  • 0 in reply to Peter Spevak
    Expert 1715 points

    Peter:

    > these opcodes are really reserved.

    Thanks! I'll file a bug with IAR.

    I'll mark this as "Resolved!"

    Atlant

**Attention** This is a public forum