|Re: [hatari-devel] Issues with cache hits/misses?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 24/05/2015 22:52, Douglas Little a écrit :
Sorry if I replied to the same stuff as you a few times - usually done
in a hurry without catching up fully.
Movem should be the instruction with the maximum possible cache
access, with up to 16 long words being read, this means a possible
max of 32 d-cache accesses, so printing a warning for value above 5
or 6 will certainly print too much useless warnings.
Each d-cache entry is a single longword, so for 16 aligned longs thats
16 hits (or misses). If misaligned it would mean an extra one at the
edge (if not in burst mode - otherwise it will likely be up to 3 more).
The 16-bit side of things doubles the number of actual fetches needed
from the bus but the cache knows nothing of that. The bus interface
handles the splitting. The cache only deals with 32bit fields, or groups
of 4x32bit in burstmode.
looking at the code in newcpu.c / read_dcache030, my understanding is
that when reading a long word, if the read is at a misaligned address,
then each subsequent read of a long word will also be misaligned.
So, for a movem that would read 13 long words for example, you would get
13*2 hits (because each individual long is misaligned), not 13+1 hits
(to read the misaligned word then to have subsequent aligned long words)
(this is without burst mode)
Unfortunately, the MC68030 User Manual example is only about 1
misaligned long word read, not several.
Tony what do you think ?