Re: [hatari-devel] Issues with cache hits/misses?

Both TOS4 and EmuTOS have:
CACR 00003111

Looking at Mikro's post here:
http://dhs.nu/bbs-coding/index.php?request=3608

It seems that in addition to both caches being enabled,
burst mode is also enabled for both.

Hmm, yes. Burst mode.

> IIRC the CPU won't fetch half of an instruction - it will try to complete
> the fetch, so it can fetch beyond the immediate longword needed. But 6
> seems like a lot to me...

Also with burst mode?

With burst mode each caches can normally fetch between 0 and 4 longs for a single read.

I don't remember what it does if the fetch crosses a 16byte boundary - maybe up to double that. Would need to read the 030 manual again.

> Hmm. The MMU shouldn't affect things. The MMU has its own cache (ATC) but
> not for instructions - for the MMU tables themselves. It can inhibit
> caching but should not affect timing unless it has to fetch a table
> entry, and should not affect hit/miss counts in the CPU caches.

According to (Amiga) WHDL documentation:
"caches on 68030..68060 are controlled by the Cache Control Register (CACR)
and the MMU! In the CACR the caches will be globally enabled or disabled.
Using the MMU single Pages (4 KiB with WHDLoad) will be marked how they can
be cached. On the 68030 a memory page can be Cacheable or NotCacheable."

No idea whether TOS uses MMU to do something like that though
(e.g. set interrupt handler code area to be cached differently).
Maybe TOS just does something differently in presence of MMU...

Yes this is what I meant by 'inhibit'. Each MMU page can be marked to prevent caching at just that location. However it doesn't add complexity to cache fetching beyond that (like the CPU fetching more cache entries just because of the MMU).

TOS does mark some memory as cache-inhibit, but IIRC its a mirror of the initial 16mb area, somewhere much higher up. Probably also does it with HW regs although the hardware provides lines for that too.