Re: [hatari-devel] WinUAE CPU core cycles issue |
[ Thread Index | Date 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 :Hi, 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; donesrc/cpu/cpuemu_0.c: 2173 src/cpu/cpuemu_11.c: 1555 src/cpu/cpuemu_12.c: 1555 src/cpu/cpuemu_20.c: 0 src/cpu/cpuemu_21.c: 0 src/cpu/cpuemu_31.c: 1878 src/cpu/cpuemu_32.c: 1847 src/uae-cpu/cpuemu.c: 3734 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...).
Hi, I'm back.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 everything.
Best regards Laurent
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |