TI MSP430
in [Embedded]
|
From: Andrew M on 12 Apr 2006 04:55 "David Brown" <david(a)westcontrol.removethisbit.com> wrote in message news:443cbcd8(a)news.wineasy.se... > Jonathan Kirwan wrote: >> On 10 Apr 2006 09:13:11 +0100, David Brown >> <david(a)westcontrol.removethisbit.com> wrote: >> >>> Jonathan Kirwan wrote: >>>> On Sun, 09 Apr 2006 00:16:04 GMT, Marc Ramsey <marc(a)ranlog.comREMOVE> >>>> wrote: >>>> >>>>> larwe wrote: >>>>>> MSP430 is a truly elegant architecture, there's no denying it. von >>>>>> Neumann simplicity, totally transparent handling of registers and >>>>>> addressing modes; I really can't find much to fault with it (except >>>>>> maybe the way info memory is handled). But: >>>>> Of course, the architecture is a simplified version of the TMS9900 CPU, which >>>>> was derived from the TI 990 minicomputer, which was in turn a rip-off of the >>>>> PDP-11 ISA, with slight changes (fewer addressing modes, allowing twice as many >>>>> registers) to avoid patent issues... >>>> I have a few comments about a pdp-11 comparison at: >>>> >>>> http://users.easystreet.com/jkirwan/new/msp430.html >>>> >>>> Jon >>> Your comments are (as far as I can tell) factually correct, but the reaction that >>> springs to mind is "so what?". >> >> hehe. No problem. >> >>> As an embedded programmer, I really do not care how a particular embedded micro >>> compares to an old minicomputer cpu (other than for historic interest, of course - >>> in which case it definitely is interesting). And as for possibly misleading >>> marketing from TI - it's not exactly new or unusual! >> >> I did point that out but that wasn't the point, which it appears I >> didn't communicate well enough on the page. My fault. >> >>> What is much more relevant is whether the register set and addressing modes of the >>> msp430 really are appropriate for their target applications, or whether they would >>> have been better off with the PDP-11 arrangement. I'm far from convinced - >>> certainly, the example you gave (PC-relative CALL) is obscure indeed, and I think >>> the benefit of more registers well outweighs this missing feature. >> >> I completely disagree. There is no question in my mind that the price >> paid was too high -- for embedded applications, I mean. >> >>> One thing that is definitely missed, however, is all four addressing modes as the >>> destination for two-operand instructions. At the very least, there should have >>> been a hack in the MOV instruction to allow @Rn and @Rn+ modes in the destination. >> >> The destination side is terrible. And it leads to expanded code size >> as well as slower execution on normal and common tasks. I've looked >> at weighing various algorithms (I write a LOT of assembly code, in my >> practice) which I've hand-written both for the existing MSP-430 as >> well as a hypothetical MSP-430 which was closer in instruction design >> to the PDP-11 and it's almost always the case that the PDP-11 >> arrangement pays off in spades. >> >> They made the wrong choice. IMHO, of course. >> >>> As for the missing PDP-11 addressing modes, they are not such a great loss. The >>> indirect modes are almost entirely superfluous when you have enough registers to >>> hold pointers in registers, rather than having to have them in memory or on the >>> stack. It's not often that pointers to pointers turn up, at least not in embedded >>> programming. Auto-decrement modes are nice, but how often are they used in >>> practice? *(p++) far outweighs *(--p), as long as you have a stack pointer and >>> push/pop instructions. Perhaps it would be a useful mode for MOV, but not >>> otherwise. >>> >>> So if you want to say that the msp430 is not as close to the PDP-11 as TI >>> marketing seems to think, then I fully agree. But if you think that's a bad >>> thing, then I disagree. >> >> Well, I use the MSP-430 and like it. It's just sad to see how badly >> an early choice demolished what might have been. Especially, because >> it wouldn't have required the invention of anything new at all and >> also because there is ample code experience which, in my opinion, >> argues very well against this choice. The additional advantages of >> having extra registers is more than offset by the damage caused by >> loss of addressing modes. The reduction in memory spills doesn't pay >> for itself. >> >> Jon > > I agree entirely on the issue of the destination addressing modes (especially for > MOV - it's not nearly as important for other instructions). As for the other > differences, I'm not convinced (although the fact that *you* are convinced is an > influence). I'd have to look at it in a lot more detail some time. > > The trouble is, 16 bits is not quite enough to make a good instruction set, at least > not with 16 registers. With 18 bits, you could get the best of both worlds. Of > course, that leads to complications during program updates, and could cause > marketing folks to lose their tenuous grip on reality (like Microchip's "14-bit > microcontroller"). The PIC is a completely different creature. Its Harvard architecture makes the choice of an arbitrary instruction width (12/14/16 bits) on an 8 bit micro possible and quite normal. The PIC gets a lot of heat in these arguments but it is effective, simple, tough, inexpensive, well represented, consistent in supply and widely available, making it a very good choice for embedded systems. Yes, coding it can be ugly, but it is extremely successful and popular due to the above points. The later PIC18Fxxxx devices code quite well. I have yet to hear a PIC designer say "it took me longer because of the architecture". Just never happens. Other issues have far greater influence on design success than architecture in most cases. -Andrew M
From: Jim Granville on 12 Apr 2006 05:37 David Brown wrote: > The trouble is, 16 bits is not quite enough to make a good instruction > set, at least not with 16 registers. With 18 bits, you could get the > best of both worlds. Of course, that leads to complications during > program updates, Why ? - there are 18 bit opcode (soft) uC now, see the PicoBlaze/PacoBlaze and Mico8. There is also a Flash uC with 22 bit opcodes. > and could cause marketing folks to lose their tenuous > grip on reality (like Microchip's "14-bit microcontroller"). :) -jg
From: David Brown on 12 Apr 2006 07:22 Jim Granville wrote: > David Brown wrote: >> The trouble is, 16 bits is not quite enough to make a good instruction >> set, at least not with 16 registers. With 18 bits, you could get the >> best of both worlds. Of course, that leads to complications during >> program updates, > > Why ? - there are 18 bit opcode (soft) uC now, see the > PicoBlaze/PacoBlaze and Mico8. 18-bit opcodes are particularly well suited to soft processors, since FPGA ram banks come in widths of 9 rather than 8. So for a Harvard architecture soft cpu, 18 bit wide opcodes are an obvious choice (unless you are going for a full 32-bit cpu). But if you want an architecture which can execute code from normal data ram, or which can easily update its own software, you are going to get complications mixing 18-bit code images with 16-bit data transfers (unless, of course, your data path is 18 bits). It is by no means impossible, but it's more complicated. > There is also a Flash uC with 22 bit opcodes. > >> and could cause marketing folks to lose their tenuous grip on reality >> (like Microchip's "14-bit microcontroller"). > > :) > > -jg >
From: anoneds on 12 Apr 2006 06:54 David Brown wrote: > Jonathan Kirwan wrote: > > On 10 Apr 2006 09:13:11 +0100, David Brown > > <david(a)westcontrol.removethisbit.com> wrote: > > > >> One thing that is definitely missed, however, is all four addressing > >> modes as the destination for two-operand instructions. At the very > >> least, there should have been a hack in the MOV instruction to allow @Rn > >> and @Rn+ modes in the destination. > > > > The destination side is terrible. And it leads to expanded code size > > as well as slower execution on normal and common tasks. I've looked > > at weighing various algorithms (I write a LOT of assembly code, in my > > practice) which I've hand-written both for the existing MSP-430 as > > well as a hypothetical MSP-430 which was closer in instruction design > > to the PDP-11 and it's almost always the case that the PDP-11 > > arrangement pays off in spades. > > > > They made the wrong choice. IMHO, of course. Interesting that the TMS9900 DOES have these modes in the destination of a MOV instruction! MOV *R1+,*R2+ is very common...
From: Gary Reichlinger on 12 Apr 2006 09:44
On Wed, 12 Apr 2006 18:55:01 +1000, "Andrew M" <noone(a)home> wrote: >The PIC gets a lot of heat in these arguments but it is effective, simple, tough, >inexpensive, well represented, consistent in supply and widely available, making it a >very good choice for embedded systems. Yes, coding it can be ugly, but it is extremely >successful and popular due to the above points. The later PIC18Fxxxx devices code >quite well. > >I have yet to hear a PIC designer say "it took me longer because of the architecture". >Just never happens. >Other issues have far greater influence on design success than architecture in most >cases. I think a lot of it is what applications you are working on. For bit oriented control, I like the PIC. Timing loops are particularly easy since all instructions take the same time to execute. If you are doing complex calculations, handling a lot of long character strings, or table lookups then you should probably use something else. |