Anyway, assuming that this kind of information is genuinely
valuable for developers, IMHO only possible concerns are:
* Do we have enough bits in trace variable for all these kind of notices?
* Does it slow down emulation so that anybody would notice?
* Is the additional code a maintenance burden?
My opinions on these in the blitter case:
* We have still 20 bits free, I don't think we're going to get so many
new ("bug" or other) trace variables that this would be an issue.
* Blitter register writes aren't so frequent that there should be any
noticeably performance impact on Hatari.
* Changes are not as small as I would like, but they're trivial, so
I think it's acceptable. See the attached patch.
Of course - for emulation it's not helpful. But debugging code is a
different scenario - it's not so much a case of deciding whether
something is a bug or not - it's more a case of knowing when a class of
thing is happening (in this case, a class of thing that is usually - but
not always - accidental).
IMO, using --trace blitter already allows to see when blitter
start/stop, and if some registers are accessed in between.
TBH this is may be enough as it is. Having it actually breakpoint/react
is only needed if that helps find where it happened - but logging the
address along with the event achieves the same (one of the benefits of
non-intrusive emulation).
Current "--trace blitter" tracks *only* control register writes,
nothing else. And with breakpoints there's the above mentioned issue,
mainly with control register.
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).
At least in case of Blitter, current traces seem inadequate
for that purpose.