Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!clyde!watmath!jsgray
From: jsgray@watmath.UUCP (Jan Gray)
Newsgroups: comp.sys.atari.st
Subject: Re: Forwarded message (UNIX on MMU-less 68000s)
Message-ID: <4159@watmath.UUCP>
Date: Sun, 4-Jan-87 08:42:44 EST
Article-I.D.: watmath.4159
Posted: Sun Jan  4 08:42:44 1987
Date-Received: Sun, 4-Jan-87 22:36:58 EST
References: <8701022135.AA07189@ucbvax.Berkeley.EDU> <7472@utzoo.UUCP> <539@eneevax.UUCP>
Reply-To: jsgray@watmath.UUCP (Jan Gray)
Organization: U. of Waterloo, Ontario
Lines: 51

In article <539@eneevax.UUCP> iarocci@eneevax.UUCP (Bill Dorsey) writes:
>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
>
>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!

Actually, I rather suspect that minix does use "segments for processes",
and since the system runs on 8086s it almost certainly limits processes to 64K.

>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.

I don't think you read all of Henry's "hit-the-nail-on-the-head"
posting.  An MMU (for address translation, not protection or virtual
memory) *is* critical to implement *fork()*.  Remember the fork()
system call returns two identical processes (except for fork() return
value).  Think how you might accomplish this without an MMU.  (You
can't simply copy the process image to another address, it probably
contains direct pointers to addresses in the original image.)  The two
schemes I can think of are:

1.  Change the C compiler so all global references are relative to
    a base register (is this what Megamax C does now?).  Now we can
    fork() by copying the image and moving the base pointer in the
    copy.  Since the 68000's X(An) addressing mode has a 16 bit
    displacement, you'll be stuck with 64K processes (unless you
    access globals in some even less efficient scheme).  Remember
    that pointers also have to be base pointer relative!

2.  Both (all?) images will share the same address space, by alternately
    swapping them in and out of that space.  Even if you keep the
    "backing store" elsewhere in RAM, this is unattractive, but
    probably easier to do than (1).  I believe this scheme was used
    to run some sort of minimal UNIX on MMU-less pdp-11s.

"Too bad the 68070 isn't going to be pin compatible with the 68000",

Jan Gray    jsgray@watmath    University of Waterloo    (519) 885-1211 x3870

[NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode, foo]
[CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche]