Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!dukeac.UUCP!bet
From: bet@dukeac.UUCP.UUCP
Newsgroups: mod.computers.68k
Subject: Submission for mod-computers-68k
Message-ID: <8702121233.AA04868@ecsvax>
Date: Wed, 11-Feb-87 12:05:00 EST
Article-I.D.: ecsvax.8702121233.AA04868
Posted: Wed Feb 11 12:05:00 1987
Date-Received: Fri, 13-Feb-87 22:39:35 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 29
Approved: info-68k@ucbvax.berkeley.edu

Path: dukeac!bet
From: bet@dukeac.UUCP (Bennett Todd)
Newsgroups: mod.computers.68k
Subject: Re: Minix/68k
Message-ID: <359@dukeac.UUCP>
Date: 11 Feb 87 17:04:59 GMT
References: <8702081739.AA11278@gorgo.att.com>
Reply-To: bet@dukeac.UUCP (Bennett Todd)
Organization: Duke User Services, Durham, NC
Lines: 18


OS/9's multitasking model won't help either UNIX or Minix run well on a plain
68000 without MMU; someone mentioned earlier that it doesn't relocate a
process after the process has begun executing (I don't know OS/9; if that was
incorrect then discount this whole note). UNIX (and Minix) found their notion
of multitasking on the fork() system call, which makes two (almost) identical
processes out of the one which invokes it. The two then continue executing
independently. This requires, at a minimum, the ability to duplicate memory
allocated to data, and allow two separate images to proceed executing. Unless
tasks are going to swap on every context switch, the data area has to be
relocatable (including pointers to data and subroutine return addresses on the
stack).

-Bennett
-- 
Bennett Todd, Duke User Services, Durham, NC 27706-7756; +1 919 684 3695
UUCP: ...{philabs,akgua,decvax,ihnp4}!mcnc!ecsvax!dukeac!bet
BITNET: DBTODD@TUCC