🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2953

MC68030 Cache Organization

#2953
From: aglew
Date: Tue, 30 Sep 1986 03:05
74 lines
4369 bytes
Motorola 68030 Cache Organization
---------------------------------

Can someone explain to me why the change in cache organization between
the 68020 and the 68030 is such a win? I don't need numbers, I'd just like
a rationalization that explains the mechanism.

NB. I'm not talking about the separate address/data lines to the I-cache
- that's obviously an improvement. What I refer to is the comment in 
_Electronics_ that goes like this:

    To improve the likelihood of cache hits, Motorola is also reorganizing
    the 256-byte instruction cache into 16 entries of four long words each
    with 4 bytes per word. The 68020 instruction cache consists of 64 entries
    each of one long word... The reorganized instruction cache, along with
    the new burst mode addressing methods, should double the cache hit ratio
    and reduce the number of times the 68030 must access the system bus.

First off, reducing the number of entries that can be independently
associated seems to be a loss, not a win. But, have they changed the cache
structure - is it fully associative now, where it wasn't before? Maybe they
just needed fewer entries so that they could do it fast enough for a 1-cycle
access with the separate A/D buses.

Do the entries have to be strictly aligned, on a multiple of 16 byte
boundary, or can they be skewed? I'd suspect the former. If so, this means
that there will be advantages to aligning the top of your inner loops on a
16 byte boundary. NOPs, anybody?

Why the emphasis on "four long words each with 4 bytes per word"? I assume
that the 4 long words reflect how the cache line is filled, by a Modulo 4
burst mode memory access. That's probably one of the big advantages of
this cache organization - it doesn't increase cache hit ratio so much as
decrease the time necessary to make good a cache miss, so that you can get
back to work quicker. Also, if you are sequentially accessing memory, as
you do in a linear instruction stream, you may have obtained the next word,
due to a burst mode line fill, before the processor asks for it - whereas
if you weren't prefetching you'd have another miss, and even if you were
prefetching but were using a slower memory access, you might not have it
ready in time.

The emphasis on `bytes' in the instruction cache probably means that it is
easier for the execution unit to pull funny sized instructions out of the
cache. Ahh, the joys of variable length instruction sets!

The orientation to longer lines, filled faster by burst mode, is probably
a good thing for an instruction cache, but one wonders whether it is so
good for a data cache. Probably is for floating point numbers, which by
themselves can fill up a cache line, or for matrix processing or graphics
where you do a lot of sequential access to data, but maybe not so good
for systems that use a lot of pointer accesses to random fields in
structures, picking out, say, only one byte on every cache line filled.
Could Motorola have given us a 64 entry 1 word per line data cache, like
the 68020's instruction cache?

(Oh, another thing: TLB address translation is done in parallel with
cache access. Does this mean that the cache is virtual? Does it do 
invalidations according to physical addresses off the external bus,
or what?)

Summing up, I see these as the tradeoffs that came into the 68030 cache:
    LOSS    fewer independent entries
    GAIN    faster association on the fewer entries?
    GAIN    faster filling using burst mode
    Longer cache lines
	GAIN	for instructions
	GAIN	for numerical and sequentially accessed data
	LOSS	for pointer/structure oriented programs?

Am I missing or confused about anything? 

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms
Technical Details
Message-ID: <5100146@ccvaxa>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!ccvaxa!aglew

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: MC68030 Cache Organization
Message-ID: <5100146@ccvaxa>
Date: Mon, 29-Sep-86 23:05:00 EDT
Article-I.D.: ccvaxa.5100146
Posted: Mon Sep 29 23:05:00 1986
Date-Received: Thu, 2-Oct-86 21:37:50 EDT
Lines: 74
Nf-ID: #N:ccvaxa:5100146:000:3802
Nf-From: ccvaxa.UUCP!aglew    Sep 29 22:05:00 1986