MAMEWorld Forums - EmuChat - Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)

> So are you trying to say that all BSR and JSR calls can't be intercepted by the MAME
> 6809 emulator and their text equivalent pushed onto a list control? e.g.

No, what I'm saying is that if you want to see a call stack you really need to know the ABI and take advantage of that.

For example on most PowerPC ABIs you can look at R1 and from that you can find previous R1/LR and follow the chain. However this isn't actually a hardware thing, it's just an ABI convention. You need to follow it on a multi-tasking OS or all hell will break loose on the first context switch, but you can implement a completely different ABI if you want to. You can't really identify calls from instruction sequences - there's no need to actually use the BL instruction, and you can do things like transform one function's frame into another to implement a tail call for example. It's very flexible.

Register window architectures like SPARC and HyperStone need strict rules concerning stack use in order for the supervisor to implement window overflow/underflow interrupts. Any* non-leaf function will have to roll the window and fill in the frame register correctly (*functions that only make tail calls are an exception).

Similarly, 68k operating systems typically use A6 as a frame pointer, so you can follow A6/A7 links to get a call stack. 68k is a quite a bit less flexible than PowerPC, so you're guaranteed to know that call instructions will push the return address onto the A7 stack, but you can still omit the frame pointer in optimised code if you track how much crap you push/pop. The sc6/sc7 commands in MacsBug follow A6/A7 links to guess the call stack; if you had much experience using it you'd remember getting completely meaningless results when an application was doing something unusual.

Some chips like PIC16x and Saturn have a hardware stack that you can walk, but it usually has so few levels that people simulate calls in other ways to avoid overflow (on HP-48/HP-49 you only have four stack levels available, and two of them are needed for the OS/interrupts, leaving you with two for your application). So walking the hardware stack won't tell you much on these systems.

The upshot is, if you want this functionality you'd need to implement something like sc6/sc7 MacsBug commands for the system you're working with. Fire up System 7 in MESS (ArBee's done a great job with this) and screw around in MacsBug to get a feel for what it does, what its limitations are, and how you could implement a similar command in the MAME debugger. But intercepting call instructions is definitely not a viable alternative.