jwhite@com50.c2s.mn.org (Jeffrey J. White) (06/06/91)
Regarding the IDT79R305x part (MIPS R3000 variant), is anyone using it or designing with it? Is it available? I also noticed from the data books I have on the MIPS part, the MMU seems to only support a very small number of contexts, 32 from what I see. I must be missing something here, 32 contexts is a fairly low number. -- Jeff White | ...!tcnet!com50!jwhite Com Squared Systems, Inc. | jwhite@c2s.mn.org 1285 Corporate Center Drive | (612) 452-9522 voice Eagan, MN 55121 | (612) 452-3607 fax
cprice@mips.com (Charlie Price) (06/07/91)
In article <1991Jun5.222454.17689@com50.c2s.mn.org> jwhite@com50.c2s.mn.org (Jeffrey J. White) writes: >Regarding the IDT79R305x part (MIPS R3000 variant), is anyone using >it or designing with it? Is it available? > >I also noticed from the data books I have on the MIPS part, the MMU >seems to only support a very small number of contexts, 32 from what >I see. I must be missing something here, 32 contexts is a fairly low >number. You can probably find out availability by talking to IDT. Integrated Device Technology 3226 Scott Blvd. P.O. Box 58015 Santa Clara, CA 95052-8015 Tel: (408) 727-6116 FAX: (408) 988-3029 If the system coprocessor control registers are the same as the standard R3000 (almost certainly true) then the processor has 64 of what I presume you mean by "contexts". The R6000 and R4000 have 256 contexts. 64 is not an especially small number though as you can see we thought that it should be larger for the faster processors. Translation: page-oriented memory management works by using (virtual-page-addr,physical-page-addr) pairs. You give the translation hardware (in our case a TLB) a process-virtual addr and it gives you back a physical-addr. To do virtual translations at hardware speed, the processor has some sort of very fast storage where it can keep a limited number of translation entries for very fast access. When the translation for the requested process-virtual address is not in the fast store, hardware or software reads main memory (via regular cache probably) to find the translation entry in the page table and puts it into the translation fast store. The problem: How do you distinguish virtual addresses for different processes? For instance how does the processor tell whether the translation entry in fast store is for virtual 0 for my "rn" process or virtual 0 for my "vi" process? The solutions: 1) flush the cached translations from the fast store on every user-process context switch. This is simple, but can be expensive. You have that fast (expensive) translation hardware there for a reason. Throwing away a lot of cached state can slow you down. 2) Add a translation "context" indicator to the hardware state of the processor and to the entries that get put into the translation hardware storage. Now the translation hardware has to match both the virtual address and the translation context identifier in the translation entry in fast store to have a successful translation. This sounds good You keep track of the translation-context value of a process in a control block somewhere (say the UNIX U-area) and when you switch to that process, you load some hardware register. All the read-from-memory-and-refill operations write the current context into the translation store along with the entry. This hasn't made the problem go away entirely. If (when) you run out of unique translation entries for active processes, you have to start all over. You flush the translation entries, "unassign" all the context values, and start over. The trick is to have enough entries to get a performance win even with the extra CPU time used to managed the contexts. Realoading the cache isn't THAT expensive for an R3000. Why is the context field not huge? In a reasonable device it can only be a finite, indeed small, field. The R3000 translation buffer (TLB) has 64 entries and is fully associative (a translation can be put in any of the entries). The fully-associative lookup circuitry for the 64 entries of 26-bit virtual identifier (20-address, 6-context) is HUGE!. The TLB is a big expense in die area. You trade die area against performance. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. MS 1-03 / Sunnyvale, CA 94088-3650