Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!rutgers!sri-spam!ames!amdahl!oliveb!sun!calypso!fish
From: fish%calypso@Sun.COM (Lorenz Fish)
Newsgroups: comp.sys.amiga
Subject: Re: Ami - MINIX problem for gurus
Message-ID: <34244@sun.uucp>
Date: Wed, 18-Nov-87 14:51:28 EST
Article-I.D.: sun.34244
Posted: Wed Nov 18 14:51:28 1987
Date-Received: Sat, 21-Nov-87 12:35:12 EST
References: <8711180347.AA10717@jade.berkeley.edu>
Sender: news@sun.uucp
Reply-To: fish@sun.UUCP (Lorenz Fish)
Organization: Sun Microsystems, Mountain View
Lines: 68


I am posting the following for Doug Merritt (ucbvax!unisoft!certes!doug).
Reply to me and I will forward your message to him:

In article <8711180347.AA10717@jade.berkeley.edu> JPARR@UREGINA1.BITNET (John Parr) writes:
>     I ran across a technical difficulty when trying to port MINIX to the
>Amiga.  How the heck can you do a fork?
> [...] Right now I can think of only two solutions.  The first is to have a
>"running" area in memory.  Then whenever a process was scheduled, its image
>would have to be copied into this area.  When finished, it would be recopied
>back to its own area. Obviously, this is not the best solution, although [...]

This is in fact the best solution, given the lack of an MMU on the Amiga.
It is, unfortunately, somewhat slow, but you can't do any better and still
support fork(). And supporting fork() is absolutely essential to a port
of MINIX.

Andy Tanenbaum (author of Minix) confirmed that this was the best solution
for MMU-less machines like the ST and the Amiga earlier this year in
a conversation following a talk he gave at Computer Literacy. And it is
the one being used in the ST port of Minix.

Note, however, that this slow swapping of process images can cease as
soon as the forked() process does an exec(). And UNIX/MINIX programs almost
always do an exec() soon after being forked(). Thus the perceptible slowdown
will be minimal for 99% of what the user will run.

The discussion above assumes minor modifications to your suggested algorithm,
mainly giving all exec()'ed processes their own memory area, and having
one shared memory area per set of identical (forked) processes.

An amusing side benefit to *always* swapping (to fast ram) is that your MINIX
programs could now have "virtual" chip ram...i.e. each process would have the
entire 512K (less overhead) to itself. On the other hand, you couldn't expect
any real time performance from more than one of these programs at a time.
Functions like animation and sound probably wouldn't get along with swapping
very well. Might be handy for switching from one inactive task to another,
though (like on the MacIntosh :-) The times when you'd get something useful
from this are minimal, actually...maybe if you had a zillion very small
processes that wouldn't all fit in chip at once, but were small enough to
swap from fast to chip ram quickly. But I digress...

A potential optimization would be to swap only the data areas of the process,
since the text (instruction) areas will presumably remain identical (never
mind self modifying code). Unfortunately it may be difficult or even
impossible to reliably differentiate between text and data in the original
object file...Amiga compilers (et al) do not guarantee keeping them separate,
but perhaps you could fix this for the Minix software. Unclear whether it's
worth the trouble. Might be no trouble at all if you're going to use a
native Minix compiler/linker.

>     (I guess that this means we will have to conceed that Intel did something
>right . . . .)

Not at all. Even though I don't know what you are referring to, it is
well known that Intel never does anything right. :-) :-) :-)

	Doug Merritt		ucbvax!unisoft!certes!doug

		 o   	Lorenz Fish	{ucbvax}!sun!fish@calypso
		 o
		 o @^_ 
		  <_~_>{
		    V

				Sun Microsystems	Mountain View, CA

		|||   disclaimer:  The company would never say THAT!   |||