MSP430 architecture

I think if you use c or any "high level" language, you really shouldn't care about architecture. The bottom line is cost, and convenience. Cost may include power consumption and other costs. Convenience may include speed, size, etc. c compilers themselves are written in c and do not run in MSP. (i.e., they are cross compilers.)

If you use assembly code (or machine code), you will see the difference Orthogonal Architecture made. But nowadays no one writes in low level language.

Thanks for your reply.

I use C but i want to know the difference made by Orthogonal Architecture, also want to understand when to use C and when Inline assembly?

Orthogonal Architecture leads to smaller and faster code. Also for assembler users it is easier to memorize instruction set.

You perhaps will benefit reading this chapter

Thanks Ilmars.. I have already gone through the chapter.

As mentioned by others, orthogonal architectures make it easier for compiler to create efficient machine code from C. (They also make it easier for a programmer to write assembly code, but this isn't very common any more.)

I might ruffle a few feathers by that last statement, but C compilers are so good nowadays that there really isn't much need to write assembly anymore. In fact, I can't think of a good reason to write assembly at all. And that's coming from a programmer who started in the days when we'd only use assembly. (Compilers didn't used to be that good... and memory was very expensive.)

BTW, if you do use assembly, I highly recommend staying away from inlining assembly. This is considered a dangerous way to mix C code with assembly since you are directly manipulating registers without knowledge or regard for how the compiler is using them. If you have to mix the two (and I cannot think of why it would be needed), you should write a C compliant assembly-coded function and call that from C. Not only is this less error prone, it's much easier to test and validate.

Scott

I agree that there is not much reason to write plain assembly programs - unless you want to do 'service' code like a boot loader, as it is quite difficult to have two C independent programs running at the same time (The C startup code always claims to be the one and only who uses all resources). Inline assembly, however, is still something you might need every now and then. If timing is crucial and you don't know how the compiler is compiling your C code. Or if you want to do efficient things using hardware features that are not possible or not supported in C. Like using the hardware multiplier MAC feature without colliding with the compiler's use of the MPY for multiplications.
In fact, you can't do some thing without assembly code (like using low-power modes), so the compiler provides 'intrinsics', to inject specific assembly instructions by using a C-style function call.

About orthogonality, sgspecker is right, it makes things easier for the compiler. It also makes things smaller and faster.
Most processors have a POP instruction that pulls a value form stack into a register. Why only into a register? Because POP works that way. On MSP430, however, a POP is nothing more than a MOV @SP+, Rx (move data form location pointed to by SP register and then increment the SP register).
And when the destination of this 'OP' can be a register, why can't it be the program counter (which turns the POP into a RET instruction) or a memory location? And why should the destination be a register? It can as well be a memory location, even an indirect one.
This makes the code smaller and faster and streamlines the microcode.
And it since "POP" is only an alias for "MOV @SP,", you can simulate your own stack mechanisms for e.g. a math stack, by using MOV @Rx, y instead. Few instructions, many possibilities.

Good comment about 'intrinsics'. I should have mentioned them, too.

You're correct that they allow us a well-defined way to gain access to specialized hardware, operations, or assembly instructions. In fact, I've often found that intrinsics eliminated the need users had, when asking about inline-assembly.