of
board!
that
other
turning
It was brief, so I will elaborate. First I meant RAM, rather than CODE, but that may be unclear....
With a register-register core, with no direct memory opcodes, all RAM access has a relatively high cost - but the reach of that ram tends to be larger. ie just loading a 16 bit pointer costs 4 bytes in a 16 bit opcode core, (but you can reach 64K bytes), then you need to get/operate/putback that variable => high code cost on ALL RAM variables.
This is the idea of opcode knee, I have mentioned before. In the
80C51, you can access 128/256 bytes in the variable length opcodes. [ Some newer 80C51's have RAM frame pointers, to extend direct meomory opcodes across all on chip RAM, but not many ]Now, if you want random access into 8K/32K of data, that's not much benefit, but in the embedded microcontroller sector, on chip RAM is commonly well under 1K.
eg a DJNZ opcode in the 80C51 is 2 bytes on a reg, and 3 bytes on any of 128 RAM locations - makes for very efficent loops. Atomic bit access is a natural on a 80C51
You also confirm that RISC was a microPROCESSOR solution, not a MicroController solution. On chip DATA memory was simply not on their radar, but it was very much on the Radar of the 80C51 and Z8 designers, who were building a single chip microcontroller. The Z8 is a good example of register-register 'done right' for a uC, and the Intel 8096 was similar.
For larger memory systems, the ARM will become the natural next 8051, followed closely by the Cortex respin by ARM, which takes a RISC that was designed as a microprocessor, more into the microcontroller space, and to improve memory usage, esp that of RAM.
- ie for a 256K Code and 64K RAM system, one would not choose a 80C51...
Once you bring RAM on chip, (and onto the designers radar), then a register frame pointer makes a lot of sense - as seen in the Z8, the 166, and IIRC, in the SPARC, where they have a nice scheme for partial register overlays, so you use some registers to pass params, and some for local variables.
-jg