devinacker
commented
8 years ago This was actually my original plan prior to writing the current implementation, but the latter point (re: step-out) made it seem less ideal. Even a relatively simple routine that just does a php at the start of the routine means having to click at least twice just to get the desired effect once, and I think in practice that's much more common than the stuff that trips it up as-is.
I'd like to make the stepping features more robust for sure, but I'd also not like to cause people to perceive some fundamental features as working "correctly" (or intuitively, etc) less often than they currently do, so it's a bit of a tricky problem.
I thought of a way you could handle step-over and step-out in the debugger that should handle 6502-style idioms like push/push/rts without getting lost, and doesn't require reading every opcode from the bus twice. For "step over", have the debugger latch the current value of the CPU stack pointer, and halt at the next instruction boundary when regs.s >= latched_s. For "step out" do the same thing, except latch regs.s + 1 instead.
The only disadvantage to this approach that I can see is that if you're in the middle of a routine that's already pushed some temporary data on the stack, "step out" will stop when that data is pulled instead of when the routine returns... but at least it's easy to see that that's what's happened and you can recover from it (you "step out" but when execution stops the previous instruction is a pla and not a jsr... so you just "step out" again)