Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 beta 4/12/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.micro
Subject: Re:  The 68010 and MMU's
Message-ID: <3@rlgvax.UUCP>
Date: Thu, 26-Jul-84 02:09:00 EDT
Article-I.D.: rlgvax.3
Posted: Thu Jul 26 02:09:00 1984
Date-Received: Fri, 20-Jul-84 07:18:27 EDT
References: <1999@sri-arpa.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 31

> 	The 68451 certainly does exist and is available, (although not in
> massive quantities).  The only format i have seen it in is the square
> LCC package though.

We make (to, in my opinion, our sorrow) a 68K-based UNIX box which uses the
68451, in a DIP the same size as the 68000 chip itself.

> By the way, the types of memory management provided by the 68010
> and the 68451 are DIFFERENT, the 68010 is for VIRTUAL memory
> implementations, (and by itself is used in the Sun processor, with
> custom memory management hardware), and the 68451 performs MEMORY
> RELOCATION only.

Not true - you can combine a 68010 and a 68451 and make virtual memory.  It
could be "demand segment loading" (which is virtual memory - ask any
Burroughs mainframe programmer), or you can even do demand paging (by using
the 68451 as a sort of translation lookaside buffer, with fixed-size small
(~2KB, say) "segments".

> 	The one thing you do need to do is always use a 68010 in ANY scheme
> that does dynamic memory management, (to wit, most UNIX implementations), as
> the 68000 has unrecoverable faults when a bus-error occurrs.

Also not true - Masscomp uses two 68000s.  The main 68K halts on a page fault,
and the other 68K services the page fault and restarts the main 68K.  Doing it
with one 68000 isn't possible (to my knowledge - maybe somebody out there
*has* squeezed blood from a stone).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy