[hatari-devel] Profiler / disassembly tests for Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Nicolas/Thomas,

WinUAE CPU core disassembly wrapper did not work at all (it ignored the 
provided FILE*) which I've now fixed:
https://www.atari-forum.com/viewtopic.php?p=487749#p487749

This isn't the first time disassembly output causes problems for 
profiling, so I though to add tests for it.

Those tests work locally now, and they also validate that symbol 
handling & breakpoint chaining (used for profiling) do work.  They work 
by comparing disassembly output with profiling information, against 
output saved to Git.

(Tests run "cyccheck.prg" from the "cycles" test, as that was 
unstripped, unlike most other test binaries.)

However, I'm wondering whether disassembly outputs [1] (e.g. cycle 
counts in them) would change often enough to be nuisance...

I.e. how often you'd think there will be changes to:
* This test program
* Handling of interrupts used by FakeTOS
* WinUAE CPU core disassembly output format
* 68000 & 030+MMU cycle counts
?

Note: I've written test scripts so that they save the output if it 
differs i.e. test update is just "mv" + "git commit".


	- Eero

[1] It's no that long as "cyccheck.prg" runs only through 188 addresses 
on 68000 before calling Pterm0(). Such a small size should mean less 
chance for Hatari emulation cycle changes affecting it.

(On 030 that program goes through 328 addresses though, with most of the 
extra ones being NOPs.  It seems to go into some error mode on 030, but 
wha it does, doesn't really matter for the profiling/disasembly testing.)