Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: net.micro.68k Subject: Re: The Motorola 68030 Message-ID: <8000007@ccvaxa> Date: Mon, 29-Sep-86 23:05:00 EDT Article-I.D.: ccvaxa.8000007 Posted: Mon Sep 29 23:05:00 1986 Date-Received: Thu, 2-Oct-86 21:38:15 EDT References: <2270@gitpyr.UUCP> Lines: 74 Nf-ID: #R:gitpyr.UUCP:2270:ccvaxa:8000007:000:3802 Nf-From: ccvaxa.UUCP!aglew Sep 29 22:05:00 1986 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? 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? (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?) 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