GARTHWILSON wrote:
I wouldn't worry about stack depth. In tests where I was making heavy use of stacks, the maximum I managed to fill up was less than 20% of page 1. However, if you have recursive routines, or a multitasking OS, or lots of local variables and environments, you may have to be more careful; but one extra return address isn't going to matter much.
A worst-case scenario might be one in which all registers are preserved prior to calling the subroutine. Assuming the 65C02, that would put six bytes on the stack each time, four for the registers and two for the return address. If the stack pointer starts out at $FF, 42 such subroutine calls would be feasible.
It's even less a worry with the 65C816 when in native mode, even though a total preservation of MPU state prior to a subroutine call would push 13 bytes in total, 10 bytes for the registers themselves and 3 bytes for the return address, assuming the subroutine was called with the JSL instruction. If the top-of-stack pointer were at $CFFF, for example, and it was decreed that the bottom of the stack was at $C000, a total of 315 such subroutine calls could be made without stack underflow.
A major concern in any interrupt service routine is performance, especially during interaction with I/O hardware. I cover some of this in my
65C816 interrupts article in the
software engineering section.
Login
Register
FAQ
Search
