Re: [hatari-devel] New version of WinUAE's cpu core

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 02/12/2014 21:25, Eero Tamminen a écrit :

> I browsed through the changes in code outside the CPU core, and
> noticed e.g. this:
> ----------------------------
>   #if ENABLE_WINUAE_CPU
> +#ifdef WINUAE_FOR_HATARI
> +		Exception(exceptionNr, ExceptionSource);
> +#else
>   		Exception(exceptionNr, m68k_getpc(), ExceptionSource);
> +#endif
>   #else
>   #ifdef UAE_NEWCPU_H
> ----------------------------
>
> Why so many defines?
Hi

for now I wanted to separate my changes as much as possible from the 
existing code, to be able to spot faster what has changed and what is 
the same since hatari 1.8.
But eventually, ENABLE_WINUAE_CPU and WINUAE_FOR_HATARI will merge.

As for UAE_NEWCPU_H, I don't know where it comes from, but from what I 
saw, it is defined only in uae-cpu/newcpu.h, so it seems similar to
!ENABLE_WINUAE_CPU

This can be cleaned later.

> And this change:
> -------------------------
> -unsigned long OpCode_GemDos(uae_u32 opcode)
> +uae_u32 OpCode_GemDos(uae_u32 opcode)
>   {
>   	GemDOS_OpCode();    /* handler code in gemdos.c */
>
> -	m68k_incpc(2);
> -	regs.ir = regs.irc;
> -	get_word_prefetch(2);
> +//	m68k_incpc(2);
> +//	regs.ir = regs.irc;
> +//	get_word_prefetch(2);
> +	(*cpufunctbl[0X4E71])(0x4E71);
>
>   	return 4 * CYCLE_UNIT / 2;
>   }
> -------------------------
>
> Why above replaces the old (commented out) code with:
> 	(*cpufunctbl[0X4E71])(0x4E71);
>
> Instead of:
> 	fill_prefetch();
>
> that is used with all the other glue functions?
With WinUAE 2.8.1, there're many more accuracy level than before,and 
depending on the one you choose, correctly incrementing PC and keeping 
other related variables up to date (like fetching) can be quite 
dangerous to do yourself (calling fill_prefetch() is not enough with 
some cpu modes)
At least, it would had several "if", and even so it's not recommanded to 
do "regs.ir=regs.irc" or get_word_prefetch(2) (what if data/code caches 
are enabled in 68020+ mode ? What if JIT is used ? And so on).
So, the trick I used to avoid handling all this in hatari-glue.c is to 
execute a "NOP". This will have the same effect of incrementing PC by 2, 
pointing to the next instruction and it will also take care 
automatically of all the prefetching and internal registers update for 
whatever cpu mode you're using.
My plan is to use it too in uae-cpu/hatari-glue.c, as it makes the code 
more "readable" (well, at least it doesn't expose the cpu'core internal 
variable), but there's no hurry, I'd rather make small incremental 
changes at the moment outside of the cpu/ directory.

Nicolas