|Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
All you say is probably right, but I really think that at least adding
the head/tail infos into the debugger would be a good add.
I've done a few tests these days with both the new and the old cpu and
compared with my Falcon.
All my tests concerned only the 68030.
I'm running a big loop with 1 move and 1 add.
On the real Falcon, it runs at 4 VBLs
On hatari old core, it runs at 3 VBLs
On hatari new core, it runs at 2 VBLs
I think we should first try to perfect the Falcon emulation, which is
still quite far from being accurate (in terms of timings).
This concerns mainly the Videl, the BUS and the 68030 itself.
Le 13/04/2013 13:34, Nicolas Pomarède a écrit :
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
* 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 not sure.
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 -
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.