Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cuae2!ihnp4!cbatt!ucbvax!cs.umass.edu!HELLER
From: HELLER@cs.umass.edu.UUCP
Newsgroups: mod.computers.68k
Subject: RE: Re: Minix to the 68k?
Message-ID: <8702131756.AA29749@ucbvax.Berkeley.EDU>
Date: Fri, 13-Feb-87 07:45:00 EST
Article-I.D.: ucbvax.8702131756.AA29749
Posted: Fri Feb 13 07:45:00 1987
Date-Received: Sat, 14-Feb-87 23:37:47 EST
Sender: steve@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 43
Approved: info-68k@ucbvax.berkeley.edu

Some thoughts about whether one *really* needs a MMU:

	First off, UNIX is not so much a multi-tasking system as a
multi-*user* system:  That is on a typical UNIX system, you are not the only
user, and it is considered very unfriendly to clobber someone else's core
image (even inadvertently).  Thus UNIX needs to worry about process memory
protection.

	If one abandons the multi-user idea (which make sense on a *small*
personal-type system, like the Amiga or ST, or even some of the slightly
bigger systems like Stride 420s or 440s), then there is not any real need to
worry about process protection - if a program gets out of control, well you
can just re-boot (i.e. reset button, power-cycling, whatever), with no great
loss (well maybe in-core file buffers...). On my Stride 440 I run CP/M-68K
under Stride's "Multi-user" BIOS. This BIOS is not really multi-user and
does not use an MMU. Instead it assumes that each "user" (who gets his/her
own copy of whatever O/S he/she is running) is carefull. This works out fine
with the p-System, which is under the control of the p-code interpreter
(which provides a sort of software MMU). Under CP/M-68K, you really have to
be carefull, but I have not had any problems. (Main thing to worry about is
disk partition sharing - only *one* user should have write access to a
partition - CP/M-68K buffers disk allocation tables.)  It is mostly a matter
of carefull programming. Also, under CP/M-68K a runaway pointer will
probably clobber the stack and very quickly get you some sort of memory
access violation (missaligned work/long ref or non-existent memory ref or
cause a rts instruction to return to the middle of you data area with a
probable illegal instruction...).

	Other notes: I believe OS9 works much like Stride MU BIOS (except
only one copy of the O/S kernel is in memory and the file system knows about
multiple processes doing I/O). The O/S on LISP Machines also use a "single
address space" model. The LISP Machines do have an MMU, but that is needed
for virtual memory management, not for process context games - that is, on a
LISP Machine, all of the processes all share the *same* data and program
areas - the only memory which is private is the stacks and machine register
sets (part of the process context). Make inter-process communication
trivial: just to a SETQ to some common, special variable.  Again, LISP
machines are not multi-user, just multi-tasking.

	Given these constraints, it should be posible to implement a
multi-tasking O/S without having to hassle with a MMU.

					Robert