| Re: [hatari-devel] Feature request/idea: cycle counting |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 31/01/2018 à 02:11, Miro Kropáček a écrit :
On 31 January 2018 at 10:25, Eero Tamminen <oak@xxxxxxxxxxxxxx
<mailto: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
<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. 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. :)
Hi
When I want to check that some instructions are correctly emulated
cycle-wise, or if I want to see how many cycles a group of instructions
is needing in some code, I'm using the cycles already availabe in
--trace cpu_disasm.
for example :
cpu video_cyc= 40780 332@ 79 : 00014566 224c MOVEA.L
A4,A1
cpu video_cyc= 40784 336@ 79 : 00014568 d2dd ADDA.W
(A5)+ [1530],A1
the value after video_cys is the global cycle position since the start
of the current VBL. So here we can see that "MOVEA.L A4,A1" takes
40784-40780 cycles.
This works well as long as all the instructions are in the same VBL.
Is that the kind of values you're looking for ?
Nicolas