TI MSP430
in [Embedded]
|
From: Mark Borgerson on 13 Apr 2006 01:27 In article <jtaq32dokr2q9pngpo5fkm216f1ufkjan3(a)4ax.com>, jkirwan(a)easystreet.com says... > 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. OTOH, perhaps the designers of the first MSP430 chips faced constraints on the instruction set based not on the desirability of the instruction operation, but on their ability to implement the instruction within the die area and power limits that they planned to meet. I would guess (perhaps simplisticly) that not all instruction options require the same silicon area or interconnect complexity. It might also be interesting to compare the number of clock cycles for some destination modes (@R3+ ) on the PDP11 or M68K with the number of clock cycles for two instructions on the MSP430. Mark Borgerson
From: Andrew M on 13 Apr 2006 02:10 "Mark Borgerson" <mborgerson.at.comcast.net> wrote in message news:MPG.1ea781372393579998a1c0(a)newsgroups.comcast.net... > In article <jtaq32dokr2q9pngpo5fkm216f1ufkjan3(a)4ax.com>, > jkirwan(a)easystreet.com says... >> 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. > > OTOH, perhaps the designers of the first MSP430 chips faced constraints > on the instruction set based not on the desirability of the instruction > operation, but on their ability to implement the instruction within the > die area and power limits that they planned to meet. I would guess > (perhaps simplisticly) that not all instruction options require the > same silicon area or interconnect complexity. > > It might also be interesting to compare the number of clock cycles for > some destination modes (@R3+ ) on the PDP11 or M68K with the number > of clock cycles for two instructions on the MSP430. > > > Mark Borgerson Also worth noting is that the MSP430 was designed pre-FLASH, when on-chip EPROM and RAM cost a lot and used a lot of power. Hence the larger register set to avoid regular ROM and RAM accesses -Andrew M
From: Jonathan Kirwan on 13 Apr 2006 05:14 On Wed, 12 Apr 2006 22:27:52 -0700, Mark Borgerson <mborgerson.at.comcast.net> wrote: >In article <jtaq32dokr2q9pngpo5fkm216f1ufkjan3(a)4ax.com>, >jkirwan(a)easystreet.com says... >> 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. > >OTOH, perhaps the designers of the first MSP430 chips faced constraints >on the instruction set based not on the desirability of the instruction >operation, but on their ability to implement the instruction within the >die area and power limits that they planned to meet. There are cases where I simply cannot accept the above vague excuse (under which probably any defect could be swept.) The missing pc-relative function call happens to be such an oversight and would have been very easily remedied in the design without impacting combinatorial delays and cycle time, power, or die size. They already had a pc-relative adder which already had a path back to the pc register for other reasons and enabling it for the call instruction would have been a very minor modification to the execution control section, very likely without any size or power impact -- just some more careful thinking _before_ starting on the implementation. And there are others that also make the MSP-430 design weaker and also couldn't have been chosen for die or power reasons, IMHO. >I would guess >(perhaps simplisticly) that not all instruction options require the >same silicon area or interconnect complexity. Not all do. But I'd rather we deal with specific issues and have you or others point out specific, detailed arguments about those. So, for example, take the case of the 'mov' I mentioned in an earlier post or else take the case of the lack of a pc-relative function call and make a clear case for die area or power limitations, etc., that deals with these specific cases. I'll add some more thoughts of my own, just to add fuel to the fire, from my own limited cpu design experiences and I'll then bring in other oddities on the MSP-430 that look more like ad hoc design and less like crafted engineering trade-offs. >It might also be interesting to compare the number of clock cycles for >some destination modes (@R3+ ) on the PDP11 or M68K with the number >of clock cycles for two instructions on the MSP430. I've no idea what you expect to gather from such a comparison. But definitely have at it, I say. Several innovations for the PDP-11 came from earlier work at CMU -- such as the idea of greatly increasing the generality of applying general purpose registers in the 8 modes. A bigger struggle for the PDP-11 instruction design team was probably to free up opcode space. In the end, I think they did pretty good. And the places they got it wrong, seem to be the same places that the MSP-430 also failed to avoid (I'm thinking about extending the address space reach, for one example.) For those interested in some of the history of not just the PDP-11 but of other computers, there is this site from one of those intimately involved (Gordon Bell, who was the VP of Engineering at DEC at some point): http://research.microsoft.com/users/GBell/Digital/DECMuseum.htm For Lewin, should it be the case that he even reads this and if he is still working out the details of his PDP-1, the above page also includes the 1960 and the 1961 manuals for the PDP-1 and the I/O manual for it, too. Jon
From: larwe on 13 Apr 2006 07:16 Mark Borgerson wrote: > IIRC, the MAC programming conventions dedicated one processor register > to point to a set of global variables---the phrase 'above A5' is "A5 worlds". Among various abominations in earlier versions of the MacOS: use of Pascal strings.
From: CBFalconer on 13 Apr 2006 15:42
Mark Borgerson wrote: > 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? Yes. > 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. My p-machine avoided that by using a call table at the end of a segment. All the destinations were relative to the table entry, and thus negative, thus leaving the full range available. So call instructions specified segment and table index value. -- "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/> |