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]