On 2 Jan 2009 at 3:25, der Mouse wrote:
Nothing says that the hardware's stack has to be
the same as the C
local-variable stack, and indeed on an architecture like that it might
be smarter to use the hardware's stack - the thing SP points to - only
for return addresses, with local variables and arguments kept on a
separate stack, maintained by the function call/return boilerplate.
Of course, that means you have to keep the data stack pointer
somewhere, since you can't keep it in SP for free....
I did say "C can probably be implemented on any binary CPU, given
enough memory and ugliness". Probably even an 8x300.
I work with both PICs and AVRs (my current project uses an
ATMega128), but both instruction sets seem to me to be more than a
bit contrived. The AVR less so than the PIC, but still on the "odd"
side of the ledger.
Why, for instance, on the AVR, am I restricted to 16-bit register
pairs X, Y and Z? Why does LPM work only through Z? Why can't I use
any register pair to address memory? To be fair, the TI MSP430 is a
16-bit chip, not an 8-bit one.
Not that the TI chip doesn't have its drawbacks. It's available in
3.3v only and doesn't match the speed of higher-end PICs and AVRs
(top clock speed for the 430 is, ISTR, 16MHz). The unified address
space imposes limits on the size of RAM and program flash. But the
instruction set's a marvel and the chip is extremely miserly with
power.
I'm not a 430 evangelist (and suspect that it will never enjoy the
popularity of the PIC or AVR, which is a shame). I'll work with any
instruction set, but I know what I'd prefer to use.
It's curious that the MSP430's instruction set is close to the GI
CP1600, where the PIC is descended from the very different 1650.
Cheers,
Chuck