Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 12/04/2013 15:52, Eero Tamminen a écrit :
> Hi,
>
> On torstai 11 huhtikuu 2013, Eero Tamminen wrote:
> > > > > Another useful thing for blitter problems - having the debugger
> > > > > notice/alert when the blitter HW registers (other than busy bit)
> > > > > are modified
> >
> > Do you mean changes in any of the registers, or or just the control
> > register?
> >
> > Easiest would be to take a copy of the register values when blitter
> > starts working and checking when blitter stops working whether any
> > of them had changed.  This would of course need to disregard any
> > regs that change while blitter works:
> > lines, words, src and dst adress and halftone bits in control register..
>
> Probably best would be to add separate trace level to blitter for
> these messages.
>
> It would be good to have common part in name for these kind of "coding
> bug detection" messages, maybe a "_bug" postix?
>
> I.e. trace option name for such blitter messages would be "blitter_bug"
> ("blitter" is used to enable control register tracing)...

I'm not sure it's easy to choose what kind of blitter access should be 
considered as "bug" or not and traced as such in Hatari.
As with the pacemaker example, we see they alter some registers while 
blitter is on.

IMO, using --trace blitter already allows to see when blitter 
start/stop, and if some registers are accessed in between.

If we want Hatari to report some possible coding bugs / bad practices, I 
think it would be better to keep traces in Hatari as they are and feed 
the output trace file to another program to do a higher level analysis 
(as you do with the python profiler tools for example).

Nicolas