TI MSP430
in [Embedded]
|
From: CBFalconer on 12 Apr 2006 09:11 John Perry wrote: > Gene S. Berkowitz wrote: > ... > >>> The coupon expires on April 15th, so hurry. >> >> ..but be aware that it's severely backordered. >> I placed my order (full price) on 25-February; I'm still waiting... >> > Well, they just told me in the verification email that it was to be > shipped at the end of April. My verification email says nothing about shipping dates! -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
From: CBFalconer on 12 Apr 2006 09:18 David Brown wrote: > .... snip ... > > 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. Hardly obscure. This, together with PC relative jumps, is what makes object code intrinsically relocatable, and I consider it a valuable feature. Now it becomes trivial to swap code segments in and out as needed. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
From: Jonathan Kirwan on 12 Apr 2006 13:47 On 12 Apr 2006 10:39:52 +0100, David Brown <david(a)westcontrol.removethisbit.com> wrote: ><snip> >The trouble is, 16 bits is not quite enough to make a good instruction >set, at least not with 16 registers. ><snip> But that's the point, David. If you've taken the decision already to use a 16-bit CISC instruction and you plan on supporting dual operand instructions, the price they paid to force (shoe-horn) 16 registers into a PDP-11 style 16-bit general concept was simply too high. I can't say what the designer of the MSP-430 actually considered in laying out the design. But looking at the result, it has some of the earmarks to me of "come hell or high water, we will have 16 registers here" and "let the resulting chips fall where they may." You can see these sadder compromises in several places. By comparison, the PDP-11 shows a carefully crafted and balanced design at each and every turn. That said, there are some features that are _enabled_ better by having 16 "registers." One of them is the concept of a constant generator. And I think that was a good choice, once they had decided to have 16 permutations available. On the PDP-11, with only 8 registers, that choice would have been somewhat more expensive to consider and would have required more time to carefully balance, looking at real code and seeing where the benefits and costs might take them. But even on the subject of the constant generator, the MSP-430 didn't implement that in a fashion which speaks to me of a crafted design -- but instead, as one that was patched together more as a chimera of various "ideas." You might think that using a constant generator as a destination would simply throw away the result and capture the expected side effects of the source operand. For example, mov @sp+, #0 might be coded up using destination mode 0 with an R3 destination. One might expect that this would simply pop the stack and throw away the result. Certainly, one would expect that the autoincrement would still take place. But it doesn't, when executed. Frankly, this is an oversight -- not a matter of crafted design. And only one of many that are found on the MSP-430. And this points up the decision to shoe-horn in 16 registers -- I think they just let the chips fall where they may and didn't do a thorough considered design. By comparison, every detail of the PDP-11 instruction screams out the care and craftsman-like attention to each and every detail. Jon
From: Andrew M on 12 Apr 2006 18:33 "Gary Reichlinger" <reichln(a)navix.net> wrote in message news:6o0q325dai7i837786qit8ed8mef61sp8e(a)4ax.com... > 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. I agree. For strings, C compilers hide much of the grief for those designers that are "pic-centric' and make workable apps that would be dreadful in assembly. The code ain't pretty though. After all, FLASH is cheap and not that many apps have timing critical string code! -Andrew M
From: Mark Borgerson on 13 Apr 2006 01:15
In article <443CFE0F.D3B04F8A(a)yahoo.com>, cbfalconer(a)yahoo.com says... > David Brown wrote: > > > ... snip ... > > > > 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. > > Hardly obscure. This, together with PC relative jumps, is what > makes object code intrinsically relocatable, and I consider it a > valuable feature. Now it becomes trivial to swap code segments in > and out as needed. Are you mixing up position-independent code and relocatable code? When I was writing Macintosh applications in the 1980s, you could generate position-independent code---where ALL references were PC relative--or relative to a base address that was derived at run time. Relocatable code was simply code that used some mechanism to allow a linker or loader to modify those addresses in the code that required adjustment depending on where the code was loaded. IIRC, the MAC programming conventions dedicated one processor register to point to a set of global variables---the phrase 'above A5' is floating in the misty sea of memory. ;-) IIRC there were limits on the segment size of position-independent code probably +/- 32767 bytes away from the PC. Mark Borgerson |