|Re: [hatari-devel] WinUAE CPU core cycles issue|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 27/02/2013 17:57, Nicolas Pomarède a écrit :
Le 27/02/2013 17:52, Eero Tamminen a écrit :
On keskiviikko 27 helmikuu 2013, Eero Tamminen wrote:
When looking into using OpcodeFamily variable in profiler, I found out
that the default WinUAE CPU core doesn't update that variable.
Here's how much it's used in the code generated for different WinUAE
CPU core variants and the old UAE core:
$ for i in src/*/cpuemu*.c; do echo $i:; grep OpcodeFamily $i|wc -l;
I.e. it's updated in most of the WinUAE CPU cores, except two of them.
When looking at gencpu.c, it's explicitly disable for those in mistaken
belief that OpcodeFamily is used just for (ST) instruction pairing.
It's indeed practically used for calculating pairing in 68000 mode.
But given it's enabled in 68030 mode, I guess it could be enabled in
68020 too (I don't think the added cost will be noticeable, so if it
can make the profiler similar in all cases...).
When I added the "accurate cycles" for the 68030, I focused on the
"cycle exact" 68030 CPU, ie cpuemu_31.c
I didn't want to break too much winuae cpu code, as I'm not sure I
understand everything into it.
I also thought that if there are things to change later in these CPUs,
it would be better not to break everything.
So, that's why I only made the changes into this specific CPU.
It could be easy to put my changes into all the 020/030/060 CPUs, but I
don't know if my approach is the good one.
I think Nicolas understands these CPUs much better than I do, and I
would prefer hatari to run only with the new CPU cores before breaking