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

[ Thread Index | Date Index | More Archives ]

Hi Nicolas,

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.

Best regards


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 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 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 - 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.

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.


Mail converted by MHonArc 2.6.19+