Re: [hatari-devel] Feature request/idea: cycle counting

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 01/31/2018 03:11 AM, Miro Kropáček wrote:
> On 31 January 2018 at 10:25, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > Hatari already provides that info:
> > https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
> > file/tip/doc/manual.html#Investigating_the_profile_data
>
> That's true  but this is not what I'm after, at least the use case is
> different here -- I'm not after profiling of existing code. I just want to
> write something and know which variant is the fastest without looking into
> instruction timing tables.

You were talking about cache hits & misses, which on 030 can have
a huge impact on performance.  That's a run-time property dependent
on what you've run before (e.g. are you doing things in a loop, how
long your loop is etc).

Even on 68000 which doesn't have caches, there's instruction pairing
to consider.

Only execution of the instructions with the CPU emulation code
considers these things, disassembly considers each line only in
isolation.

I.e. you need to run the code for cycle information.

If you have enabled profiling, disassembly contains cycle
information for the executed addresses.


> Sure, I can do that via the profiling feature
> but it's so time consuming that it's easier to look it up in the docs,
> especially if I want to compare one or two instructions. :)

For that kind of static & i.e. less accurate information,
there could be a separate tool.

You could e.g. use my little python m68k instruction script
as base for writing one:
	http://eerott.mbnet.fi/hatari/sources/instructions.py
:-)


That tool already provides Hatari debugger breakpoint condition
that one can use to catch specified instruction.  With that,
you don't need to write example code yourself, just run some
other code until it hits the breakpoint for the instruction
you wanted, and you get its cycles.


	- Eero