Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!cbmvax!rutgers!iuvax!pur-ee!j.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ain
From: ain@s.cc.purdue.edu (Patrick White)
Newsgroups: comp.sys.amiga
Subject: Re: Ami - MINIX problem for gurus
Message-ID: <1570@s.cc.purdue.edu>
Date: Thu, 19-Nov-87 11:06:39 EST
Article-I.D.: s.1570
Posted: Thu Nov 19 11:06:39 1987
Date-Received: Sun, 22-Nov-87 08:01:59 EST
References: <8711180347.AA10717@jade.berkeley.edu>
Reply-To: ain@s.cc.purdue.edu.UUCP (Patrick White)
Organization: PUCC Land, USA
Lines: 45

In article <8711180347.AA10717@jade.berkeley.edu> JPARR@UREGINA1.BITNET (John Parr) writes:
 >Hi all:
 >     I ran across a technical difficulty when trying to port MINIX to the
 >Amiga.  How the heck can you do a fork?
 >     The problem is this.  When a process is first loaded in from disk, it
 >is nicely relocateable up until the time it runs.  Once it runs, however,
 >any pointers that it uses will be absolute addresses.  When copying the
 >parent over to the child, all pointers will still point to the parents
 >data area.  Amiga DOS must run up against similar problems, what does it do?

   Let me mix a few ideas from my IBM PC days, and see if it creates a
possible solution:
   1) if the code is reentrant, then no problem here -- this seems like a
      valid assumption since few C programs that I have seen modify the
      code itself.
   2) stack is easy too if you know where it is and all stack references
      are done via offsets from the base of the stack (not necessarily a
      valid assumption, but one I'm willing to make).
   3) one problem is the data segment.  Now, on the IBM (in one of it's
      infamous "memory models") the data is referenced relative to a
      data-segment-pointer.  I believe that the Manx compiler for the
      Amiga does something like this too (my manuals are at home so forgive
      me if I'm wrong on this).
   4) the biggest problem I can see, is the heap memory.  Code usually
      deals with this stuff using "absolute" addresses (rather than relative
      addresses), and I can find no way without an MMU to fix this.  Copying
      the malloced memory around is the only way to make this work, and that
      will mean copying lots of little pieces of memory.
   
   It seems to me that there really is no "clean" way to implement a fork
without an MMU, but you can implement a vfork easily -- if the program execs
immediately, then nothing is lost (and it's faster too).
   
 >     (I guess that this means we will have to conceed that Intel did something
 >right . . . .)

#include opinion-warning

   Only thing they did right was segments -- makes multi-tasking easier, but
other things a pain when the segments are too small to contain an entire
program, or all it's data.

-- Pat White
UUCP: k.cc.purdue.edu!ain  BITNET: PATWHITE@PURCCVM   PHONE: (317) 743-8421
U.S.  Mail:  320 Brown St. apt. 406,    West Lafayette, IN 47906