Re: [hatari-devel] WinUAE and 030 cache hits/misses?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Sun, 27 Jan 2013 18:11:59 +0100
schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

> At first glance, the code seems to be the same for m68k_run_2ce
> (cycle exact) and for m68k_run_2p (non cycle exact, prefetch ON)
> 
> Thomas, maybe you've got an idea here.
> 
> Is it normal that "CurrentInstrCycles" and "nWaitStateCycles"
> variables are *always* zero at the time do_specialties() gets called
> in cycles exact mode and they are values in non cycle exact mode ?
> 
> Le 26/01/2013 22:08, Eero Tamminen a écrit :
> > Hi,
> >
> > On lauantai 26 tammikuu 2013, Laurent Sallafranque wrote:
> >> Le 26/01/2013 20:26, Eero Tamminen a écrit :
> >>> I noticed that per-instruction cycle information is zero
> >> just with the WinUAE "exact" CPU model.  If I use
> >> "--machine falcon --cpu-exact false", I do get cycle
> >> information.
> >>
> >>
> >> Do you mean there's something missing ?
> >> Just point me to the clue, I'm interrested.
> > With "--cpu-exact true" "CurrentInstrCycles" and "nWaitStateCycles"
> > variables are *always* zero at the time do_specialties() gets
> > called, as that's where the debugger is called.
> >
> > With "--cpu-exact false", those variables have also other
> > than zero values when debugger is called.

In cycle exact mode, the CPU core counts each cycle seperately, so the
global "CurrentInstrCycles" variable is not needed and not set.

And nWaitStateCycles is always cleared right before do_specialties is
called, so you never should see a non-zero variable here, no matter
which mode you are using.

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/