Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!mash From: mash@mips.com (John Mashey) Newsgroups: comp.arch Subject: Re: Memory hierarchy Message-ID: <1653@spim.mips.COM> Date: 30 Mar 91 22:51:42 GMT References: <1998@kuling.UUCP> <2832@shodha.enet.dec.com> <1991Mar28.152952.18380@rice.edu> Sender: news@mips.COM Organization: MIPS Computer Systems, Inc. Lines: 35 Nntp-Posting-Host: winchester.mips.com In article <1991Mar28.152952.18380@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes: >I think it's happening now. >To the aggressive compiler or programmer, the memory hierarchy >is already extensive > > registers > cache > (secondary cache -- does MIPS have one already?) > TLB > RAM > disk To answer the questions: sure. 1) R3000s have occasionally had secondary caches bolted on the outside (ex:SGI MP). This is fairly similar to 680x0 and i486, where the primary design point seemed to be for 1-level caches, but allowing 2-level, but with less support built directly in to the chip. [Maybe designers of these would comment if this impression on priorities is accurate.} 2) R6000s were designed from day 1 to use 2-level caches. 3) For R4000s, the primary design point in many ways is for 2-level caches, although the 1-level single-chip version is also an important point, and gets more prevalent with time as the on-chip caches get bigger, reducing the performance delta between R4000 & R4000+scache for some applications. A distinct difference found in the R4000s is the inclusion of full 2-level cache-coherency control on the chip. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94086