|Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 12/04/2013 21:41, Eero Tamminen wrote:
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.
I'm still not convinced that this kind of "what's good or wrong"
analysis should go in Hatari itself. What someone calls a bug could be a
completly wanted behaviour for someone else.
Also, let's face it : in the best cases, there could be a few dozen
demos released in the near future that could use it, but 95% of all
demos were already released 10 years or more. Those demos might have bad
coding practices, it could be interesting to see them if someone wants
to study how it was done, but apart from that, no one will use this
information to fix those demos.
We're also releasing a new Hatari version every 8 months or so ; having
the analysis in Hatari itself is harder to maintain, the emulation code
is already complicated in some case (see video.c), do we really want to
had more code added to it that is not directly emulation related ? I'm
With an external tool that would parse the current traces, it would be
much faster to update the analysis ; a perl or python script can easily
be updated without releasing a whole new version of Hatari.
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
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.
Why so ? For example, if you have a trace that tells blitter started,
you can check all IO traces related to the blitter and see if some
occured before the blitter finished its work.