>Tapley, Mark wrote:
On Dec 16, 2015, at 9:22 AM, Jerome H. Fine <jhfined...@compsys.to> wrote:
Note that for many CPUs, adding values (a push) results in the
stack pointer becoming numerically smaller (unsigned of course).
Internally, the code would handle the actual arithmetic.
(Warning: assembly language noob talking, please disregard if I see to be
making no sense.)
1) Does the debugger enhancement trigger a stop on overall size of stack
pointer or on cumulative changes? Or could it be selectable (maybe via a
negative argument?)
Here’s what I’m thinking: suppose a routine is expected to remove things from
the stack sequentially, then branch at some point to a subroutine. I want the
debugger to halt execution when it branches. So I want the stop to occur when
the stack pointer first increases, even if it has already decreased several
times and its new value (on branching) is lower than where it was when the
debug command was issued.
2) Some machines (6809, which is the only one I’m familiar with) have a rapid-response branching mechanism for real-time control applications (on the 6809 it’s a Fast Interrupt input). Fewer registers are pushed onto the stack so the service routine can execute sooner. Is there a way to handle this situation? Say I expect two levels of subroutine calls, each stacking a full set of registers, but instead I get for the second subroutine a Fast Interrupt and don’t stack enough registers to trigger the debug counter to halt execution.
Hope this is useful.
- Mark
Yes, it is useful since it helps to be aware of what other
systems do. So thank you.
For those of you who might not have known, this is the
Y01.16 Symbolic Debugger from RT-11 and in particular
the SDHX.SYS variant. From the point of view of
interrupts, when stopped at a breakpoint, the complete
system is FROZEN - including RT-11 itself which is the
operating system that is being used on the PDP-11.
As for the user's stack, that is not even a factor since the
Symbolic Debugger has its own stack and executes in
Kernel mode. In fact, one of the other enhancements was
to ass code to monitor the size of the stack for the Symbolic
Debugger - which also allowed that stack to decrease. That
was especially helpful since the stack must be in Low Memory
in order to handle interrupts and subroutine calls.
And as for the user's program stack, there is no effect at all.
What the Symbolic Debugger does is save all of the user's
registers, including the stack pointer of course. The enhanced
code would then compare the original value of the Stack
Pointer (actually as noted after the current instruction had
been executed) with any subsequent value to determine if the
conditions had been met to stop the execution of additional
instructions, assuming that the value of the Stack Pointer
was included (via value2 and / or value3) in the command
to execute more instructions.
Jerome Fine
