I tend to agree that anything that can increase the internal power and flexibility of the 8051 while not increasing external circuit requirements and maintaining code compatability with the existing 8051 architecture is a good thing.

Have I ever need more stack space than what is provided by an 8-bit SP? No. Would it be nice to have? Sure, since like others have said, this would make the implementation of higher-level languages easier rather than forcing such languages to be severely limited or implement ugly kludges to work.

I disagree that just because a larger stack could potentially be used by compilers for local variable storage that that means people want to make a PC out of the 8051. It's just a useful and common way to implement a compiler. And while it wasn't reasonable to implement such a thing on the 8051 15 or 20 years ago, the power of 8051's has obviously increased. With 100 MIPS 8051's possible and easily being able to address 16MB of external RAM using some derivatives (Dallas and Analog Devices come to mind), having a maximum 256-byte stack size seems like an unnecessary limitation. Implementing an SP1 SFR would allow a stack size of up to 64K and would be 100% compatible with existing designs.

Likewise, I see no reason why there shouldn't be a configuration bit in some new SFR that indicates whether the stack should be stored in IRAM or in XRAM. If a design is going to have 64K external RAM, why should the MCU force us to use the 256 bytes of IRAM for the stack? Sure, compilers can implement code to put the stack in XRAM, but that's an ugly kludge. It should be handled by the MCU and be just as functional in assembly as in a higher-level language.

Regards,
Craig Steiner