Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!amdcad.UUCP!bandy
From: bandy@amdcad.UUCP.UUCP
Newsgroups: mod.computers.68k
Subject: Re: Submission for mod-computers-68k
Message-ID: <8702190311.AA01999@amdcad.AMD.COM>
Date: Wed, 18-Feb-87 22:11:31 EST
Article-I.D.: amdcad.8702190311.AA01999
Posted: Wed Feb 18 22:11:31 1987
Date-Received: Fri, 20-Feb-87 02:25:58 EST
References: <8702181830.AA20074@sun.Sun.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Advanced Micro Devices, Sunnyvale, California
Lines: 61
Approved: info-68k@ucbvax.berkeley.edu

>From: cmcmanis@sun.uucp (Chuck McManis)
>With all the discussion about fork() and why you can or cannot do it
>without an MMU, I thought of a solution that I haven't seen proposed
>yet. 
>
> [why not just get a clean copy of the unrelocated executable off of
>  disk,ala amiga's dos, and copy the data space and stack?]

>I have not figured out if one would have to muck with such things as
>duplicating the current memory allocated by the parent process, 

Yes, you would.

>and
>if so fix up such things as linked lists of data structures. 

It would be difficult.  For the compiler to put enough (uh) "bugs" in to allow
the operating system to know what to fool with during a fork would be a
*large* performance hit.

As to duplicating the stack, what happens when you have char *s; auto ca[666];
s = &ca; in your scheme?  Whoops!  Pointing at the wrong area of memory!

In fact, I wrote a little article today about how Tanenbaum's friend who is
doing the ST port is working it - and since you probably don't read
comp.sys.atari.st, I'll duplicate it here:

From: bandy@amdcad.UUCP (Andy Beals)
Newsgroups: comp.sys.atari.st
Subject: Multitasking discussion

Well, as you may know, Andy Tanenbaum has mentioned a number of times
that a friend of his is working on a port of minix to the ST.  Well, I
was curious as to which method was being used (planned on being used? I
don't know how far along that port is), so I dropped a note off to him
and found out that when processes are loaded, they are relocated on the
fly -- apparently the same method that the Amiga folks use.  When a
process forks, the child is "swapped" to somewhere in memory (wherever
there is enough room).  When the scheduler starts the child, it swaps
out the parent (to somewhere else in memory), swaps the child to where
the parent [was] and starts running the child -- this way all the text and
data references are okay. 

In most cases, the child will exec so the new process being loaded in
can go anywhere and the parent process can go back to where it
belongs.  This all should happen within one scheduler tick, so you
won't have to do more than four copies of the parent's process image if
you're careful // however, if you're really careful, you could get away
with two copies (for the fork/exec case) -- copy the parent, run the
child (where the parent was), when the child execs, copy the parent
back to where it belongs You might be able to get away with not copying
the parent back *just shuffle the pointers), but with no read-only
pages (no mmu), you have no guarantees that the child hasn't scribbled
all over the data or text pages).

Yes, I know, this sounds gross, but it isn't too bad -- after all, if you do
want your machine to go faster, you can wait until one of the home-computer
manufacturers comes out with a cheap machine with an MMU and then run Minix
on it.
-- 
Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683