Re: [hatari-devel] Hatari debugger question

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 10/08/2013 19:18, Eero Tamminen wrote:

> > It would add an overhead, whether it's a big one or not depend on the
> > power of the computer used to do the emulation  (but it would imply a
> > check on each read/write to see if further debugging function should be
> > called or not, so that's an overhead)
>
> That debugging functionality overhead (SPCFLAG_DEBUGGER bit check on
> every instruction) is already there, and wouldn't change.
>
> Only additional overhead would be storing the memory access address to
> internal Hatari variable in all the relevant places of the CPU emulation.

Problem is that some instruction can do several memory access in one go 
; consider a movem for example that would read 7 words. Maybe only the 
second word need to be monitored for read access. But in the current 
debugger's flag handling, the debugger is evaluated only once *after* 
the end of the current cpu instruction.

As you can see, it wouldn't work with current implementation, because it 
would require to store a list of all memory accesses made by an 
instruction and check this list at the end of the current cpu 
instruction when evaluating SPCFLAG_DEBUGGER.

Even so, it wouldn't work if you want to monitor blitter's accesses to 
ram, because blitter doesn't evaluate SPCFLAG_DEBUGGER.

So, the only solution is to add in every .B/.W/.L memory access 
something like :

if ( spcflag & SPCFLAG_MONITOR_RAM)
{
 ... call debugger functions
}

This means spcflag & SPCFLAG_MONITOR_RAM needs to be evaluated in every 
memory access, so that will be a new overhead.

Nicolas