Re: [hatari-devel] Hatari v2.1 regressions in many demos

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 18/02/2018 à 20:11, Eero Tamminen a écrit :
> Hi,
>
> On 02/18/2018 08:36 PM, Eero Tamminen wrote:
>  > This leaves still these to be bisected:
>  > - Hex Pistols
>  > - "_"
>
> I wasn't able to bisect these.  They are broken also with 2.0,
> and the early 030 instruction cache fix.  "_" works only when
> CE mode is disabled, and Hex Pistols with old UAE CPU mode.
>
>
> So in summary, there are two significant regressing commits in v2.1:

Hi

thanks for bisecting these, but in the end, it's always the same problem 
: some changes to cpu cycle counting for 68030 will improve some 
programs, but at the same time it can create regressions.
The changes are often related to prefetch or cache, because those are 
the part of the 68020/30 pipeline that are not described in deep enough 
details in Motorola docs ; some memory accesses can be stalled while a 
cpu instruction does sthg else, then the pipe can be filled again in an 
other place, the main goal of the 68020/30 is to try to always use the 
bus when some memory accesses are required, kind of "stacking" accesses 
if you like.
The problem is that the rules used by the cpu are not described anywhere 
to explain all the cases we see on real HW.

So for now, 68030 CE mode is not perfect and will give these kind of 
regression :(

Nicolas