Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site x.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!hplabs!pesnta!amd!vecpyr!lll-lcc!lll-crg!seismo!harvard!think!mit-eddie!cybvax0!frog!x!rfm From: rfm@x.UUCP (Bob Mabee) Newsgroups: net.arch Subject: Re: 386 info Message-ID: <830@x.UUCP> Date: Tue, 5-Nov-85 22:06:23 EST Article-I.D.: x.830 Posted: Tue Nov 5 22:06:23 1985 Date-Received: Mon, 11-Nov-85 06:11:28 EST References: <965@mcnc.mcnc.UUCP> Reply-To: rfm@x.UUCP (PUT YOUR NAME HERE) Distribution: net Organization: Charles River Data Systems, Framingham MA Lines: 15 In article <965@mcnc.mcnc.UUCP> jnw@mcnc.UUCP (John White) writes: (summarizing Intel release on the new 386) >First, if all 32 entries in the cache >are used, then one must be freed up. As the access and dirty bits may have >been changed, the entry must be written back to the page table. This is a bug (or misquoted). The accessed and dirty bits have to be written back to memory immediately they are set, using a bus-lock read-alter-rewrite cycle to set just the bit of interest. Otherwise the chip can not be used (reasonably) in a multi-cpu system. Also, even with a single processor there would have to be a way to force the dirty bits to get written out before the system can look for a good page to evict. -- Bob Mabee @ Charles River Data Systems decvax!frog!rfm