Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!eneevax!iarocci
From: iarocci@eneevax.UUCP (Bill Dorsey)
Newsgroups: comp.sys.atari.st
Subject: Re: Forwarded message
Message-ID: <539@eneevax.UUCP>
Date: Sun, 4-Jan-87 03:15:07 EST
Article-I.D.: eneevax.539
Posted: Sun Jan  4 03:15:07 1987
Date-Received: Sun, 4-Jan-87 05:38:05 EST
References: <8701022135.AA07189@ucbvax.Berkeley.EDU> <7472@utzoo.UUCP>
Reply-To: iarocci@eneevax.UUCP (Bill Dorsey)
Organization: never
Lines: 27

In article <7472@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>Doing any form of Unix on the ST is hard because of the lack of MMU.  The
>IBM PC, revolting though it is, does have the half-baked excuse for an MMU
>that the 8086 itself supplies.  Unix on the ST is not impossible, just a
>lot of work and rather awkward -- fork() is the bad part on a system with
>no relocation hardware.
>-- 
>				Henry Spencer @ U of Toronto Zoology
>				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

I beg to differ.  If mimix runs on an 8086 system, it could be ported to a
68000 system with little difficulty.  If, as I gather you believe, mimix were
to use segments for processes, it would require that 64k be the minimum and
the maximum limit for all processes.  That would be ridiculous!

Contrary to popular belief, an MMU is not critical for all multi-tasking oper-
ating systems.  If the operating system doesn't implement virtual memory, it 
can function quite well without an MMU.  There are quite a few examples of
operating systems falling into this category.

In summary, if you are willing to put up with processes being able to read
each others address space as well as write to it, and virtual memory isn't
needed, then an MMU isn't all that critical.  Properly functioning processes
wouldn't access memory outside of their address range, anyway.  The practical
effect might be more frequent crashes during the debugging stage of programs
as opposed to core dumps.  But under normal use, you wouldn't notice the
difference!