Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!fan
From: fan@CS.UCLA.EDU
Newsgroups: comp.sys.m68k
Subject: Re: Question:  on-chip or off-chip MMU?
Message-ID: <5721@shemp.UCLA.EDU>
Date: Tue, 28-Apr-87 11:57:19 EDT
Article-I.D.: shemp.5721
Posted: Tue Apr 28 11:57:19 1987
Date-Received: Thu, 30-Apr-87 00:41:19 EDT
References: <5635@shemp.UCLA.EDU> <58500002@gorgo.UUCP>
Sender: root@CS.UCLA.EDU
Reply-To: fan@CS.UCLA.EDU (Roy Fan)
Organization: UCLA Computer Science Department
Lines: 38

In article <58500002@gorgo.UUCP> bsteve@gorgo.UUCP writes:
>	1) On-board MMUs require micro-bus cycles just like separate MMUs,
>	   and depending upon the uP architecture may take the same number
>	   of cycles.

	Don't the current uP use pipelining to increase the
throughput, for example 80386, 32532?  Thus there could be no
micro-bus cycles required.

>	2) We can't add virtual cache with an on-board MMU. The advantage of
>	   virtual over physical cache is that it operates in parallel with
>	   the MMU cycles and returns in nearly half the time on a hit,
>	   whereas the physical cache always requires a complete MMU cycle.

	We could put a small cache on the chip (if there is enough
room).  Of course, if there isn't enough room, we will need to go
off-chip.

>	3) Some applications (small signal processing, etc.) don't really
>	   require the MMU, so why should one drive up the cost of the uP
>	   by adding one on-board?

	Yes, you're right.

>	4) Some architectures support stackable multiple MMUs that operate
>	   parallel. One obviously cannot do this if the MMU is on-board.

	If the MMU is off-chip, usually it should be large enough to
ensure some high hit ratio.  Then by increasing the number of MMU
wouldn't increase the performance much.  However, it would increase
the board space.

	I guess for performance-wise, on-chip MMU is faster than
off-chip MMU.  But then there are just too many factors to be considered.

Roy Fan
University of California    fan@cs.ucla.edu
Los Angeles