[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

> Btw. I was thinking of adding a "history" command to Hatari debugger, with
> which you can set how many instructions back the debugger will remember
> execution and be able to show previous values.
> 
> For first I was thinking of storing just the PC to backtrack branches that
> have happened e.g. before a breakpoint (without flooding the console like
> disasm trace does), but it could later store also all CPU registers and
> anything else you might be interested about...

I already did a quick implementation of this as its own command:
------------
> dsphistory 
DSP history isn't enabled!
> dsphistory 8
Enabled and allocated 8 items for DSP history.
> c
Returning to emulation...
SPEED: 146.1 VBL/s (558/3.8s), diff=-48.2%

CPU=$e09b5c, VBL=1227, FrameCycles=70, HBL=0, LineCycles=70, DSP=$51
> dsphistory 
Last DSP PC positions from oldest to latest:
8. $0451
7. $0451
6. $0451
5. $0451
4. $0451
3. $0451
2. $0451
1. $0451
> dsphistory 20
Changed CPU history size from 8 to 20.
------------

but I started to wonder how it should actually be used...

Should CPU execution history be tracked always so that debugger just allows
changing the ring buffer size for that and showing the result, or should it
be always specifically enabled in debugger?  (when it stores also something
else on every instruction execution)


Or what if it would be part of the profile command?


One more possibility might be storing the history only for branches.
I wasn't thinking of checking the instructions themselves, just whether new
PC address differs more than "limit" from previous PC address.

The PC offset limit could be something that user sets, so one could use it
e.g. to catch:
* all last N instructions with value set to 1
  (for seeing tight loop repeats without knowing about loop counter value)
* only jumps to ROM & back with value set to large enough number.

What do you think?


	- Eero