Language-specific CPUs was Re: uIEC/SD == AWESOME!

[Chuck Guzis]

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