Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.sys.m68k Subject: Re: Question: on-chip or off-chip MMU? Message-ID: <354@winchester.UUCP> Date: Wed, 29-Apr-87 05:08:04 EDT Article-I.D.: winchest.354 Posted: Wed Apr 29 05:08:04 1987 Date-Received: Thu, 30-Apr-87 07:13:19 EDT References: <5635@shemp.UCLA.EDU> <4244@nsc.nsc.com> <1401@ames.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 44 In article <1401@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: >In article <4244@nsc.nsc.com> grenley@nsc.UUCP (George Grenley) writes: >>In article <5635@shemp.UCLA.EDU> fan@CS.UCLA.EDU (Roy Fan) writes: >>> What are the important deciding factors in designing a MMU >>>on-chip or off-chip? >I would like to put in a plug for an on-chip MMU, an on chip (relatively >small) instruction cache (works with virtual addresses in the current >context only), and an off chip data cache (may not be necessary with >enough registers). The reasons: (bunch of reasons... msot of which are quite reasonable) >5) If there is more room on the chip after the MMU is on, the next step is to > put the ARITHMETIC back on the chip (no extra FPA necessary then), and the > next step after that is to divide the ALU into segmented functional units, > then add vector instructions with fully segmented functional units, and to > make sure you have enough registers, with everything in "RISC style" (no > microcode, lots of random logic); >6) Then, after all that is on the chip, and you still have room ( :-) ) > put the data cache back on the chip. Given Hugh's general wishes expressed elsewhere [including good FP], the only piece I'd disagree with here is 5), and we're probably not really disagreeing. For sometime, it will be very difficult to get a high-performance FP unit on the same chip as (even a RISC) cpu. Our FPU is bigger than our CPU, and if the chippers had dared make it bigger, they would have used the space to eliminate another cycle or two, rather than trying to cram the CPU and FPU together. For some time, you can either have low-medium FP performance on the CPU chip [a legitimate design point], or you can have high-performance FP off-chip. Note: I'm talking the differences between 2-cycle DP Adds versus the 30-50 cycles or more prevalent in coprocessors these days. The only other disagreement [and it only by omission], is that the argument started as cache versus MMU. Hugh extended it logically to include most of the other elements that might be there. There's one that's left out, and it's actually one of the highest priorities, and it really doesn't cost too much: put all the cache control for external caches onto the chip. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086