MSP430
Home Politics IBM PC Programming MSP430 LTSpice Tools Empty

 

Feet of Clay

My first impressions about this processor from Texas Instruments were fantastic. At the time, I'd heard about its extremely low power design but it was the instruction set that caught my attention, early on. It really looked, in the marketing hype, to be very, very nice. I didn't know much about the hardware and the functional units available on these CPUs, but I was honestly impressed with what I'd seen about the instructions.

Over time, those initial impressions have been transformed through practical experience. What was, at first, almost a disinterest in the functional hardware has been replaced by a deepened and earned respect from what has been achieved by the designers of this microcontroller. Wherever I look more deeply, my appreciation only continues to grow as I become more familiar with the well-crafted design choices. What starts out as "that's nice, too" develops into "this is impressive!" A similar change has also taken place in my views about the instruction set design. What started out as a real excitement from what I'd read early on has developed through this last half-year of active programming experience using the assembler to become an equivocal, "well, I like it fine, but ..." point of view.

This MCU has earned my abiding respect and appreciation. It's an excellent microcontroller and I can recommend it heartily. I'm using it in several designs now and I plan to continue doing so into the foreseeable future. But in my opinion, the instruction set designers failed to live up to the high standards this MCU otherwise sets.

This paper doesn't discuss the excellent timers and capture/compare units, the fantastic (and somewhat intricate) clocking system, the very competitive capabilities of the input/output pins, the handily segmented flash memory, the very short start-up times of the DCO, the useful DMA controllers, etc. These aspects of the CPU deserve your examination -- they are stunning. Instead, this paper focuses on the instruction set and the picture there is less impressive. While this processor's instruction set might, on first approach, seem to have "a head of gold and arms of silver," keep in mind that it also has feet of clay.

First Impressions

I was actually quite impressed by my first exposure to the MSP-430 instruction set. My reaction to reading some of the details about the MSP-430 instructions was to notice just how similar they seemed to my recollections of the DEC PDP-11. I mean -- I was really liking what I saw. Pretty darned good, it seemed.

I noticed that it also had 16 registers and was momentarily happier. Heck, the PDP-11 had 8 and although that was nice enough, 16 would sure be better. I also noticed the inclusion of special constants implied by certain register usage and was even happier, because I'd had good experiences with another processor having a similar feature (MIPS R2000.)

But there was a nagging feeling there, too. Something just didn't fit. I then began wondering how they could get 16 registers into a 16-bit instruction with both source and destination and still preserve those excellent addressing modes in the PDP-11? I hoped the designers had worked some very special magic here, but my apprehension grew -- a sense of dread that they'd made some poor choices that cost the instruction set design more than it got back in return.

RISC

Is the MSP-430 a RISC processor? I don't think so.

In the introduction of Texas Instruments' (available here as slaa024.pdf):

MSP-430 Family
Mixed-Signal Microcontroller
Application Reports

Author: Lutz Bierl
Literature Number: SLAA024
January 2000

You can find that in Section 1.1, Lutz Bierl says as one of his bulleted points,

"RISC structure -- 27 core instructions."

I think this is a seriously misleading statement, if perhaps in the end rather harmless.

David Patterson and John Hennessy arose as two key advocates of a RISC approach to CPU design during the early to mid 1980's. They were the principal founders for MIPS and the MIPS R2000 was their first widely available, and commercially successful implementation of their insights. In their book, "Computer Organization & Design," David Patterson and John Hennessy describe the RISC inspiration as the realization that assembly programming was rapidly being replaced by the use of compilers and that the measure of a computer system wouldn't be how well a human programmer could wield the instruction set, but how well the compilers could use it. (See pages 195 and 425, for example.) Their point seemed justified -- at the time, new innovations in compiler technology were rampant. As were new ideas for MIMD and VLIW. John Ellis' "Bulldog: A Compiler for VLIW Architectures" in 1986 was one excellent example of this excitement and work (it's his Ph.D. thesis, available from MIT Press.)

However, this activity for new ideas for compilers has remained far more a hope than reality. In part, this is perhaps because of Intel's dominance as well as the rapid growth of IC technology, by leaps and bounds, allowing traditionally CISC designs to incorporate many of the RISC ideas while remaining externally CISC. Still, despite the need to support Intel's dual FP units at its registration station or several integer units in the PPro and follow-on Pentium II, et al, almost no compiler tool supported these features. Even in the case of the incredibly successful Intel x86 line of CPUs, compiler technology largely remains about where it was two decades ago. Many of the hardware features which could be used well to great advantage in some cases remain unused or poorly used.

In any case, a RISC design is identified by such details as replacing the control store and sequencing logic, traditionally found in CISC processors, with hardwired logic -- adding more functional units and/or register files, for example. RISC is also identified by fixed instruction lengths (so that the control stores wouldn't be required), and so on. Some of the controversial decisions were to avoid delays associated with register use interlocks and, with the control store area freed up and used for pipelining and the inevitable branch delay slots, to execute the instruction following the branch even when the branch was taken. The Alpha, in its time, carried this concept forward in a 64-bit architecture, by refusing to allow byte fetches, simply because the lane-change hardware required would have introduced an additional few nanoseconds into the stage's path timing.

By the time I'd read the comment from Lutz Bierl, I'd already shaken the idea that the MSP-430 was a RISC design. The MSP-430 does NOT rely on a fixed fetch-size for its instructions nor exclusively upon load/store for moving data in and out of the CPU. No branch delay slots typical of RISC; etc. Addressing modes *are* limited, but more because of the available encoding symbols that TI gobbled up in arranging for 16 registers and not because they were hewing to some RISC philosophy. Similarly, the instruction set *is* limited, but again because of pressure on the instruction encoding and not because of an approach which was RISC-centered.

The MSP-430 has many similarities with the PDP-11 instruction set and the PDP-11 has long been the symbol, in fact the very epitome of what it was to be CISC. Even before the term CISC existed, the PDP-11 represented it. Perhaps in a case of revealing himself in the same chapter and on the same page, Lutz Bierl makes the point in chapter 1, on page 1-2, that:

"The MSP-430 is capable of emulating almost the complete instruction set of the legendary DEC PDP-11."

I remain completely unconvinced by unsupported claims the MSP-430 should be called a RISC processor. But I'm still going to take a clue from Lutz Bierl's admission above and compare the MSP-430 with the PDP-11. It's a comparison worth considering.

Registers

Both processors place the program counter (PC) as an addressable register for general use. This detail was one of the defining characteristics of the PDP-11, in fact, and practice has shown it to be an excellent idea. In combination with carefully considered addressing modes, this provides a very powerful tool. PC-relative addressing, in-line constants, and other important ideas are immediately developed from this.

Both processors also provide built-in support for a stack and arrange for the stack pointer (SP) to be another addressable register. In the PDP-11, this fact combined with the auto-postincrement and auto-predecrement addressing modes removes the need for distinct PUSH and POP instructions, for example. In the MSP-430, their lack of an auto-decrement mode means they needed a separate instruction code for PUSH.

PDP-11 Register Set

The PDP-11 provides a total of (8) 16-bit registers, all of which can be used in conjunction with their general addressing modes, but two of those also have an additional special nature.

They are:

  ·  R0           general purpose
  ·  R1           general purpose
  ·  R2           general purpose
  ·  R3           general purpose
  ·  R4           general purpose
  ·  R5           general purpose
  ·  R6 or SP     stack pointer
  ·  R7 or PC     program counter

The PDP-11 also supports a status register, but as there was no need to use the status register with all the addressing modes, it was placed in a special memory location instead. (In the MSP-430, they take advantage of the fact that several of the addressing modes make little sense with the status register to construct constants, instead. But there are cases where the use of these special modes with the status register become illegal instructions or instructions which execute in undocumented and strange ways.)

Thus, the PDP-11 has (6) 16-bit general purpose registers for applications. The PC and SP have specialized use, though I have to say that the SP isn't nearly as privileged in the PDP-11 as it is in the MSP-430. Other registers are quite usable as stack registers due to the orthogonal and comprehensive PDP-11 addressing modes.

MSP-430 Register Set

The MSP-430 provides a total of (16) 16-bit registers, all of which can be used in conjunction with their addressing modes, but two of those acting just as in the PDP-11 and another two of those are dependent on the addressing mode in determining their function.

They are:

  ·  R0 or PC     program counter
  ·  R1 or SP     stack pointer
  ·  R2 or ST     status, constants +4 and +8, abs mode
  ·  R3 or CG     constant generator for -1, 0, +1, and +2
  ·  R4           general purpose
  ·  R5           general purpose
  ·  R6           general purpose
  ·  R7           general purpose
  ·  R8           general purpose
  ·  R9           general purpose
  ·  R10          general purpose
  ·  R11          general purpose
  ·  R12          general purpose
  ·  R13          general purpose
  ·  R14          general purpose
  ·  R15          general purpose

Unlike the PDP-11, the MSP-430 places the status register as part of the register set, rather than as a memory location. This is fine when referencing it directly, but since there is no need for using the status as part of the other available addressing modes the MSP430 uses those extra addressing modes to select different behaviors when R2 is specified. In particular, absolute addressing and the constants +4 and +8 (these constants, I regret to say, appear to not work on many of the MSP-430's, if not all of them.)

Further, there is no R3 at all! Instead, that register is used in combination with source addressing modes in order to generate different constants, namely -1, 0, 1, and 2. As a destination, it is likely to do 'strange things.'

Thus, the MSP-430 has (12) 16-bit general purpose registers for application computations.

The MSP-430 appears to have a nice register scheme. It doubles the number of registers available for applications and provides a space-efficient method for generating commonly used constants.

Is there a cost for having a lot of general purpose registers, though?

Addressing Modes

Stored data needs to be accessed and manipulated. Registers for both processors allow their registers to be used as accumulators and for general computations. In addition, both processors allow their registers to be used as memory pointers in several convenient ways - either as direct pointers, pointers which automatically adjust themselves, or as indexing registers.

But this is exactly where we discover the high price paid by the MSP-430 CPU designers when they decided upon 16 registers in their register selection field(s) of their 16-bit instructions. This is where I believe the PDP-11 designers got it right and the MSP-430 designers bungled.

PDP-11 Addressing Modes

The PDP-11 provides a total of (8) addressing modes which can be used in combination with any of their (8) 16-bit registers and, in the case of double-operand instructions, can be fully used for either or both operands.

They are:

  ·  Register                         ·  Register Indirect
  ·  Auto-increment Pointer           ·  Auto-increment Pointer Indirect
  ·  Auto-decrement Pointer           ·  Auto-decrement Pointer Indirect
  ·  Indexed Pointer                  ·  Indexed Pointer Indirect

Essentially, each of the first four modes on the left side have a complementary indirect mode, listed on the right side, above. The right-side modes give one additional level of indirection, when needed. The assembler uses an '@' as a specifier to indicate these last four indirect modes. For example, R5 is 'register' and @R5 is 'register indirect' mode.

A constant value can be placed in a word following an instruction by using the auto-increment mode together with the PC register. Absolute addresses are handled similarly, except that it's with the auto-increment indirect mode - using the immediate constant as an address instead of a value. PC relative addresses are handled using the indexed pointer mode with the PC register, essentially indexing memory as relative to the current location. This is something, for example, the MSP-430 does not have.

Except for the first mode, register mode, all of the above modes generate a memory address that specifies the location holding the contents to be operated upon. An exception is made in the case of the JSR and JMP instructions, where the contents aren't used. In that case, it is the generated address and not the contents at that address that gets placed into the PC. In other words, a 'JMP R5' is illegal while a 'JMP @R5' is legal. One cannot jump to a register, but it's quite possible to jump to where that register is pointing. Those two instructions operate at one less level of indirection and it is this fact, born of wise instruction design, which allows PC-relative function calls with the JSR instruction on the PDP-11 (lacking on the MSP-430.)

MSP-430 Addressing Modes

The MSP-430 provides a somewhat more confusing arrangement for its addressing modes - part of the price the designers paid in order to make room for those 16 registers. For instructions with only one operand, it supports a total of (4) addressing modes. But for double-operand instructions, those four are only supported for one of the operands (the source); for the other operand, the destination, a mere two modes are supported. By comparison, the PDP-11 supports all addressing modes for both source and destination and, in my opinion, handles those it supports smarter, as well.

For the source in double-operand instructions and for single-operand instructions, they are:

  ·  Register
  ·  Auto-increment Pointer
  ·  Indexed Pointer
  ·  Register, Indirect

For the destination in double-operand instructions, they are:

  ·  Register
  ·  Indexed Pointer

It's hard to express just how spartan this is, when compared with the PDP-11. (No, this doesn't make the MSP-430 a RISC CPU! The addressing modes which remain in the MSP-430 dispel that assertion quite clearly.)

Texas Instrument's documentation claims to add three more addressing modes to this list, calling them 'symbolic,' 'absolute,' and 'immediate' modes. But symbolic and immediate modes are just special cases of the above modes using the PC register. This isn't anything like a new addressing mode. The PDP-11 also supports these methods, but doesn't push them as distinct modes. This selection of the use of certain registers and then calling them different addressing modes seems more a marketing thing on Texas Instrument's part. Regardless, if they deserve to be called out here with special notice then they deserve to be added to the PDP-11 list, too.

Now, to be fair, absolute mode is a special handling of indexed mode using R2 and perhaps it does deserve a special note. But it is, in effect, nothing more than a hack designed to bring in a needed addressing mode not present in the MSP-430, namely the auto-increment indirect mode. (In the PDP-11, this mode automatically delivers absolute addressing when the PC register is used, so no special case was required.) In this case though, unlike the PDP-11, it only applies to one register and is not generalized.

PC-relative addressing of scalar data is handled just like it is in the PDP-11, using the indexed pointer mode with the PC register. But, in what appears to have been an oversight, PC-relative addressing of functions via the CALL instruction cannot be handled directly on the MSP-430. Where the designers of the PDP-11 seem to have carefully arranged for this, the MSP-430 designers appear to have completely forgotten about this very useful feature. The implications of this oversight by the MSP-430 CPU designers is that it now takes 7 cycles, 4 instruction words, and a spare register for computation in order to make a PC-relative function call.

To elaborate on this oversight, chapter 9 of the MSP430 Application Report Book mentioned earlier discusses how to code PC-relative calls, this way:

  MOV PC, Rn           ; Address SC+2 ?> Rn
  ADD #SUBR?$, Rn      ; Add offset (SUBR ? (SC+2))
  CALL Rn              ; SC+2+SUBR?(SC+2)) = SUBR

This uses 4 words, 7 cycles, and scratches a register. This is the kind of thing that happens when you select the "PC relative calls" option in a C compiler for the MSP-430. This kind of work-around was avoidable, too, with foresight.

That's not the whole story with the MSP-430 addressing modes, either. The MSP-430 does support auto-increment mode and thus, in combination with the PC register, the use of immediate-mode constant values. But it does not support an auto-increment indirect mode, so special handling of one of the existing modes has to be used in order to support absolute addressing.

In addition, the MSP-430 combines certain uses of addressing modes and R2 and R3 in order to provide efficient access to the constants, -1, 0, 1, 2, 4, and 8. Well, almost. As I understand it, the constants based on R2, namely 4 and 8, don't work. It's a documented bug and, I gather, there is no intent to fix the problem with revisions to the CPU dies. It may be fixed in newer product lines, though.

The MSP-430 addressing modes mentioned above cannot be applied to both operands in the case of two-operand instructions - there just isn't room in the instruction for it, due to the number of bits required for specifying registers. So this results in just two modes being available for the 2nd operand, in those cases:

  ·  Register
  ·  Indexed Pointer

(I mentioned these earlier.) This is a rather constrained circumstance, even though the selection of the indexed pointer mode as the other alternative preserves the PC-relative and absolute addressing modes.

Summary

In summary, the MSP-430 instruction set designers sacrificed orthogonality in its addressing modes in order to support a larger number of registers. Several useful tricks were applied in order to save the situation, but those they managed to implement also served to increase the specialized nature of addressing modes in the MSP-430 and those they failed to implement (PC relative calls, for example, which must be emulated) can only leave one wondering what they were thinking about.

The MSP-430 reserves an entire bit in the instruction to select between word and byte modes. But the PDP-11 was also able to support byte and word mode accesses, where needed, as well as a full complement of instructions, including integer multiplication and division and a set of floating point opcodes. The PDP-11 also uses a symmetrical form for the addressing modes which extends to both operands in two-operand instructions. (The PDP-11 also balanced the range field for branch offsets with the need for a variety of opcodes - something I won't discuss in detail.)

The MSP-430 designers made a pivotal choice (misguided, in my opinion) for 16 registers and in the process found themselves making sacrifices, even while retaining the more important addressing modes and adding some creative adaptations within the limitations they accepted in order to provide some modest but attractive compensations (e.g., the constant generator.)

I like the MSP-430 a lot, despite these warts and problems. Frankly, the hardware is impressive and the MCU remains excellent.

Appendix

Format I Instructions

(MOV, ADD, ADDC, SUB, SUBC, CMP, DADD, AND, BIT, BIC, BIS, XOR)

Format I instructions use two operands; a source and a destination (or 2nd source, e.g., CMP.) The source field uses four bits to designate the register and two bits to designate the addressing mode. The destination field uses four bits again to designate the register and only one more bit to designate the addressing mode. They play some 'games' with R2 and R3 in order to expand the addressing modes, as can be seen here:

Source:
  Mode Reg  -- Description --
   00  R0   PC register direct
   00  R1   SP register direct
   00  R2   status register
   00  R3   constant 0
   00  Rn   Rn register direct

   01  R0   x(PC), PC relative address indirect, "symbolic mode"
   01  R1   x(SP), stack offset indirect
   01  R2   x(0), absolute address indirect, "absolute mode"
   01  R3   constant +1
   01  Rn   x(Rn), register offset indirect

   10  R0   @PC, dangerous to use, not recommended
   10  R1   @SP
   10  R2   constant +4 (doesn't work)
   10  R3   constant +2
   10  Rn   @Rn

   11  R0   @PC+, immediate mode, #N, value follows instr.
   11  R1   @SP+
   11  R2   constant +8 (doesn't work)
   11  R3   constant -1
   11  Rn   @Rn+

Destination:
  Mode Reg  -- Description --
   0   R0   PC register direct
   0   R1   SP register direct
   0   R2   status register direct
   0   R3   constant 0 (acts weird, though)
   0   Rn   Rn register direct

   1   R0   x(PC), PC relative address indirect, "symbolic mode"
   1   R1   x(SP), stack offset indirect
   1   R2   x(0), absolute address indirect, "absolute mode"
   1   R3   constant +1 (acts weird)
   1   Rn   x(Rn), register offset indirect

For comparison purposes with the PDP-11, here are the instruction fields listed for both, in the case of two operand instructions:

DOUBLE OPERAND INSTRUCTIONS MSP430 PDP-11
Instruction Opcode Field 4 bits 4 bits
Source Field 6 bits 6 bits
Destination Field 5 bits 6 bits
Byte/Word Specifier 1 bit opcoded, if needed

Format II Instructions

(PUSH, RRC, RRA, CALL, SXT, SWPB, RETI)

Format II instructions have one operand, a source and/or source and destination combined. The field uses four bits to designate the register and two bits to designate the addressing mode. (Except, RETI doesn't really use the operand.)

For the operand in these instrutions, see the entries for the source operand in the double-operand, Format I instructions.

Some Comments

  1. Using the constant generator, R3, as a destination might seem interesting. For example, one might it to simply pop the stack and throw away the value, with "mov.w @SP+, #0" -- effectively popping the stack and sending it to the constant generator (where it would be thrown away.) But the actual instruction shown fails to exhibit the correct side-effect on the SP register, too. No idea why. So, this probably is one of those 'don't do' addressing modes.
  2. It appears that using R2 as a constant generator for the source operand simply doesn't work for PUSH instructions. Texas Instruments has an "errata" out on this issue (their CPU4 bug) and it doesn't appear that they intend to fix the problem in later revisions of their chip dies. Instead, they've modified the assembler to generate the immediate mode constant.

 

Feel free to email me.

Last updated: Saturday, July 31, 2004 10:20