Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!pioneer!lamaster
From: lamaster@pioneer.arpa (Hugh LaMaster)
Newsgroups: comp.sys.m68k
Subject: Re: Question:  on-chip or off-chip MMU?
Message-ID: <1401@ames.UUCP>
Date: Tue, 28-Apr-87 11:36:00 EDT
Article-I.D.: ames.1401
Posted: Tue Apr 28 11:36:00 1987
Date-Received: Thu, 30-Apr-87 00:36:43 EDT
References: <5635@shemp.UCLA.EDU> <4244@nsc.nsc.com>
Sender: usenet@ames.UUCP
Reply-To: lamaster@pioneer.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 57

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?


>
>>	Question 3 :  if there is only enough room for either a cache
>>or a MMU, which one will prevail?
>
>I would guess cache.  CPU memory requirements are outrunning the ability
>of DRAM to keep up.
>
>
>George Grenley


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:

1)  It is nice when people build compatible architecture systems from your
    chip, as they are more likely to do with an on chip MMU, because it is
    easier to port software;

2)  The kinds of problems that I work with benefit a lot more from an
    instruction cache than a data cache (Cray and/or Control Data have been
    building very high performance machines for years with an instruction
    cache only, and no data cache);

3)  You can't put a large cache on a chip anyway;

4)  Data caches on chip will complicate multiple processor implementations;

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.  



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")