Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.sys.atari.st
Subject: Re: Forwarded message
Message-ID: <7487@utzoo.UUCP>
Date: Tue, 6-Jan-87 20:27:29 EST
Article-I.D.: utzoo.7487
Posted: Tue Jan  6 20:27:29 1987
Date-Received: Tue, 6-Jan-87 20:27:29 EST
References: <8701022135.AA07189@ucbvax.Berkeley.EDU> <7472@utzoo.UUCP> <539@eneevax.UUCP>, <10979@sun.uucp>
Organization: U of Toronto Zoology
Lines: 40

> What Henry was probably referring to is the segment registers that the
> 80x86 family has. They offer a certain amount of code relocatability...

Right.  It's relocation, not protection or virtual memory, that is crucial
to implementing Unix fork() without serious performance trouble.  Virtual
memory is nice but not important for many things (the Unix I am typing
this on doesn't have it).  Protection isn't vital if you tread carefully
when/if doing program development.

On a 68000 without an MMU, like the ST, the only way to do relocation is
with extensive cooperation from the compiler.  And the resulting code will
be more complicated and slower than normal 68000 code for the same program.
Possible, but not wonderful.

You can do fork() without relocation if you are willing to have only one of
the two (or more!) processes "swapped in" -- in memory at the location they
expect to be running at -- at once.  This is a performance hassle no matter
how you slice it, and making it run quickly requires either a *fast* disk
(I'm talking Fujitsu Eagle, not $500-20MB-microcomputer-junkbox, and *most*
*certainly* not microcomputer floppy!) or else a lot of spare memory.  It
might be viable on a 1040ST if you keep program size down, although I'd
still be a bit worried about all that memory copying.

If you're willing to admit that you are *not* implementing Unix proper, you
can get away without fork for a lot of purposes.  Berkeley's awful "vfork"
kludge will suffice for the more common requirements, particularly if you
are willing to rewrite occasional bits of code to make them work in the new
environment.  And if you aren't going to implement anything resembling fork,
then of course it's possible, as witness many multitasking systems running
on unprotected machines.

> The biggest problem of porting MINIX would be porting the C compiler,
> since compiler design breaks down into two camps, the parser and the
> code generator. You would literally have to rewrite half of the compiler
> to port it. 

Note also that MINIX does not include compiler source, as I recall.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry