I really don't want to start a philosophic war here :) ----- Ursprüngliche Nachricht ----- Von: Grant Edwards Gesendet am: 06 Apr 2011 16:37:46
>> There's a difference between a lie, not telling the whole truth and >> simplifying things. The MSP isn't a CISC too. It's more RISC than >> CISC > I disagree. It lacks almost all of the characteristics typical of a > RISC architecture: > * fixed, single-clock execution? No. > * fixed width instructions? No. > * load/store architecture? No. > * pipelined? No. > * Harvard architecture? No. > * branch delay slot? No > * small instruction count? Yes. Well, almost all of the above are cause by each other and not separate 'achievements'. A fixed single clock execution as well as teh load/store architecture require harvard architecture, as you require separate instruction and data bus to fetch the next isntruction in the same cycle as reading/writing data. You could do it with a von-neumann architecture only when having dual-port ram, which is slow and expensive. The branch-delay slot is a result of the fixed single-clock execution and the pipelining. It is really nothing you _want_ to have, but something you'll get inevitably if you don't want to break the pipeline. And the MSP actually IS pipelined. During execution of the last step of an instruction, the next instruction is fetched and decoded. Sicn ethe MSP can do a calculation 'on-the-fly' instead of requiring a single pipeline stage for it, the pipeline is really short. But as long as the destination of an operation is not memory, the execution of the operation and the next command fetch are interleaved. fixed width instructions are required for fixed sinngle-clock execution. One won't work without the other. It is again nothing desireable. e.g. loading a 32 bit value into a 32 bit register requires two cycles and 8 bytes code. On MSP, it takes one instruction, two cycles and 4 bytes of code. In a relaxed interpretation, the MSP uses fixed-with instructions. Other than with RISC systems, every instruction always has the same width, no matter what the values of the parameters are. And always has the same execution time. (this is no longer true for the MSP430X set which has varying execution times for the PUSHM/POPM instruction) > Not all "RISC" architectures have all of the above, but simply having > a small instruction count just isn't good enough IMO. On the contrary, that's the only criteria. A small instruction count of fast instructions compared to a high instruciton count of complex and slow instructions. All the other 'criteria' listed are jsut the result of an (early) attempt to achieve this goal. The cited description of a RISC machine does not define how to do it but rather describes one way to implement it. That most implementations more or less followed this proposal does not mean that any other (successful) approach to achieve the same goal is invalid. Else it would have been a RISHAPFSCIFWILSAC. Which the MSP definitely isn't :) > I really like the MSP430 architecture, but it's not a RISC processor. > It's an elegently stripped-down CISC processor. Well, I like it too, but it is definitely not a stripped-down CISC. It is a fresh start with the RISC idea in mind, but not following the established implementations of this idea. Saying that it cannot be RISC without having the listed attributes is like saying you may not call yourself a human without blonde hair, blue eyes and being tall. (which is nonsense, as we all know) :) However, I think this has gone far enough. I'd love to restart this discussion on the TI forum. I believe, quite a few other people would love to join us there. This mailing list is surely not the right place, now that the technical basics of the MSP have been 'processed'. JMGross. ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
