Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!tektronix!tekecs!frip!andrew From: andrew@frip.gwd.tek.com (Andrew Klossner) Newsgroups: comp.arch Subject: Re: 88K table walk Message-ID: <10738@tekecs.TEK.COM> Date: 13 Dec 88 05:43:55 GMT References: <3798@pt.cs.cmu.edu> Sender: andrew@tekecs.TEK.COM Organization: Tektronix, Wilsonville, Oregon Lines: 35 [] "The way I read the initial data sheet it doesn't look like the 88200 caches address translation tables if you access them during a table walk." That's right. "The OS will actually be working with the tables as data. I assume that data accesses would load the table entries into the D-cache." the hardware design requires that segment and page tables be in cache-inhibited pages. Maybe it would be safe not to cache-inhibit those pages and be sure to do cache flushes before the MMU does a table walk, but the documentation doesn't say so. My guess is that segment and page tables are not cached simply because it would make the hardware design very hard. The MMU and cache are already working in parallel, because the cache begins its search when the virtual address first shows up, at the same time that the MMU begins the virtual to physical translation. (The cache starts with the low 12 address bits, which are the same for virtual and physical, then uses the other physical address bits when the MMU has them available.) Giving the MMU the ability to break into the cache cycle on a BATC/PATC miss, then restarting the cache cycle, seems awfully complicated. There are 56 PATCs, for a total of (56*4k)=224k bytes addressability. The biggest instruction or data cache is 4 88200s for a total of 64k bytes. Therefore, a gross analysis suggests that any PTEs will evaporate from the data cache before they drop out of the PATC cache. (I like the idea of caching the segment table, though.) -=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP] (andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]