Re: [hatari-devel] Memory access tracing

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 11 elokuu 2013, Nicolas Pomarède wrote:
> On 11/08/2013 02:59, Eero Tamminen wrote:
> The point of using SPCFLAG_MONITOR_RAM is to optimise the tests when no
> read/write accesses breakpoints are used, only "standard" breakpoints.
> 
> Let's consider a function to handle write to RAM :
....
> Now if we change it to :
> 
> void	handle_write_16 ( uint32 address , uint16 val)
> {
>    if ( spcflag & SPCFLAG_DEBUGGER )
>      {
>        Call_Debugger_Code
>      }
>    /* copy val to address */
>    ...
> }

Only debugger code that needs to be run in these cases is setting
some variables.  In minimal case it's:
	MemWriteAddress = addr;

Which shouldn't be that much slower than doing an if instead:
	if (spcflag & SPCFLAG_MONITOR_RAM)
		MemWriteAddress = addr;


Once I have the patch, it can be measured, but if it turns to have
any noticeable impact, I'd rather put it behing an ifdef than if  [1].


> That's why I think that to speed up decision, we should have another
> flag SPCFLAG_MONITOR_RAM (or MONITOR_MEMORY or whatever).
> 
> When a breakpoint is set and it doesn't involve monitoring read/write
> accesses (as the ones available today), we only set SPCFLAG_DEBUGGER .
> 
> When a breakpoint is set involving accesses, we set SPCFLAG_DEBUGGER |
> SPCFLAG_MONITOR_RAM.
> 
> This way, there's a first dichotomy in handle_write_16 and the
> breakpoint analysis is ran only if there're really some memory accesses
> to check. Else, we get the usual behaviour where spcflag is only tested
> at the end of the current instruction.

What kind of syntax you suggest to debugger for enabling memory
monitoring?

[1] It's an extra step that user needs to remember to do everytime he wants
to use memory access breakpoints, or get rid of the overhead for that...


> it will work ; but if the user has not defined breakpoints to really
> monitor read/write, it will be a waste of ressource and we will call
> debugger on every read/write, even if no breakpoints are possible. This
> would be a huge slowdown.

Btw. Of the optional debugger features which have cost only when enabled,
the one having largest difference to performance is DSP caller profiling,
partly because there are several DSP instructions per each CPU instruction.

That needs to do heavy operations on *each* instruction, e.g. binary search
the DSP symbol table to check whether it was one of the several thousands of
symbol addresses to which calls user wanted profiler to track...

When one adds on top of that same for the CPU side, plus the worst frame
profiling which will post-process profiling data on every Bad Mood game
frame, and disassemble all the instruction addresses to disk whenever frame 
is slower than any earlier one, that has quite noticeable effect on how
responsive the game is!


Regardless of how the CPU instruction memory access monitoring will be done,
it has minuscule performance impact compared to that. :-)



	- Eero