Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!lll-crg!qantel!intelca!clif
From: clif@intelca.UUCP (Clif Purkiser)
Newsgroups: net.arch
Subject: Re: Re: 386 Architectural Description
Message-ID: <142@intelca.UUCP>
Date: Mon, 18-Nov-85 13:26:53 EST
Article-I.D.: intelca.142
Posted: Mon Nov 18 13:26:53 1985
Date-Received: Wed, 20-Nov-85 08:26:55 EST
References: <531@petfe.UUCP> <5671@amdcad.UUCP> <1771@peora.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 29

> > This is a paging cache, not an instruction or data cache. That is,
> > instead of poking through the page tables for each virtual address
> > generated by the program, you cache the virtual to physical address
> > mapping for 32 pages. This saves a lot of time.
> 
> Does the 386 let you invalidate entries in the paging cache from outside?
> -- 
> Shyy-Anzr:  J. Eric Roskos
> UUCP: Ofc:  ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
>      Home:  ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer
>   US Mail:  MS 795; Perkin-Elmer SDC;
> 	    2486 Sand Lake Road, Orlando, FL 32809-7642

Yes,  loading the page directory root register (CR3) with a Mov CR3, Reg
instruction invalidates all of the entries in the TLB.

Also a task (process) switch which loads a NEW value into CR3 invalidates
the TLB.  But if you are only using one set of page tables in your system
you probably wouldn't want to invalidate the TLB so only new values in CR3
invalidate.

However there is no hardware pin which lets use flush the TLB.
-- 
Clif Purkiser, Intel, Santa Clara, Ca.
HIGH PERFORMANCE MICROPROCESSORS
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif
	
{standard disclaimer about how these views are mine and may not reflect
the views of Intel, my boss , or USNET goes here. }