Re: [hatari-devel] WinUAE CPU core cycles issue

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

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; done
src/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.


	- Eero

> When I looked more into this, both OpcodeFamily and nWaitStateCycles [1]
> seem to be used when calculating  cycles taken by video (including
> spec512 mode and MFP timer-B) and Blitter.  The default WinUAE CPU core
> doesn't keep either of these properly up to date.
> 
> So it's no wonder that many WinUAE CPU core cycles values are bogus. 
> That will then naturally cause also DSP code to be run out of balance
> with CPU.
> 
> 
> 	- Eero
> 
> PS. In *old* UAE core do_trace() function, comments or opcodes are wrong:
>   ...
>         if (opcode == 0x4e72            /* RTE */
>   ...
> 
>             || ((opcode & 0xf0f0) == 0x5050 /* DBcc */
> 
>   0x4e72 is STOP instruction and DBcc is matched with:
> 	(opcode & 0xf0f8) == 0x50c8