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

[laurent.sallafranque@xxxxxxx]

Hi,

Yes, this would be fine, also for cycles timings counting.
I don't know if a global variable is the best way to do it or changing the functions to return the state, but we need this information.

For the cycles counting, in terms of timings, what is the difference between an instruction miss and hits ?

I mean, in case of cache hit, the cycles to take into account are the "motorola cache cycles", whereas in non cache using, it's the "motorola non cache cycles".
But what value to take into account in cache mode ON and cache miss ?
(Should we refer to the non cache table, or still refer to the cache table but add a value for the cache filling) ?
I think the cache filling reads 1 long word at a time, meaning multiple access to the memory, but how does it really work ?

Laurent



----- Mail original -----
De: "Eero Tamminen" <oak@xxxxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Lundi 21 Janvier 2013 12:08:01
Objet: Re: [hatari-devel] WinUAE and 030 cache hits/misses?

Hi,

(Sorry about the wrong mailing list address, KMail started offering
the berlios address as recipient name expansion without me noticing.
I've removed it from my KMail "recently used addresses" now.)

On maanantai 21 tammikuu 2013, laurent.sallafranque@xxxxxxx wrote:
> > Is WinUAE CPU core able to detect cache hits/misses?
> 
> According to the work I did last year on the 68030 cycles, I would say
> yes and no ;)
> 
> According to the new core code, it seems that the 68030 cache is taken
> into account. See newcpu.c (fill_icache030, update_cache030, getcache030
> and the same functions for d cache)
> 
> So it seems that the 68030 cache management is implemented. I don't know
> if it is used actually, but I think it is (we should have a look at the
> memory access in the 030 prefetch instruction to be sure of that).
> 
> But the cycles are certainly not taken into account correctly.

The cycles are less interesting for profiling than the information
whether there was a cache miss.   To optimize code, it and data access
should be organized so that it keeps within cache as well as possible.

There seem to be:
* separate cache functions for 020, 030 and 040
* no exports any variable that tells about cache hits or misses
  (and the functions are static inlines)

In the 030 icache case Doug is interested about, the code looks like this:
----------
STATIC_INLINE void fill_icache030 (uae_u32 addr, int idx)
{
        int lws;
        uae_u32 tag;
        uae_u32 data;
        struct cache030 *c;

        addr &= ~3;
        c = getcache030 (icaches030, addr, &tag, &lws);
        if (c->valid[lws] && c->tag == tag) {
                // cache hit
                regs.prefetch020addr[idx] = addr;
                regs.prefetch020data[idx] = c->data[lws];
                return;
        }
        // cache miss
        data = mem_access_delay_longi_read_ce020 (addr);
        if ((regs.cacr & 3) == 1) { // not frozen and enabled
                update_cache030 (c, data, tag, lws);
        }
        regs.prefetch020addr[idx] = addr;
        regs.prefetch020data[idx] = data;
}
----------

One possibility would be just to add a global variable which potentially
changes its value on each call to the icache functions, depending on whether
the instruction was in cache or not.

It would look like this:
---------
        if (c->valid[lws] && c->tag == tag) {
                // cache hit
+               bCacheMiss = 0;
                regs.prefetch020addr[idx] = addr;
                regs.prefetch020data[idx] = c->data[lws];
                return;
        }
        // cache miss
+       bCacheMiss = 1;
---------

Would this be fine?


	- Eero