Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!decuac!felix!preston
From: preston@felix.UUCP (Preston Bannister)
Newsgroups: comp.os.minix
Subject: Re: Why the 8086 architecture is wonderful :-)
Message-ID: <85126@felix.UUCP>
Date: 2 Mar 89 20:34:12 GMT
References: <13428@ncoast.ORG>
Sender: daemon@felix.UUCP
Lines: 61

From article <13428@ncoast.ORG>, by allbery@ncoast.ORG (Brandon S. Allbery):
> As quoted from <84154@felix.UUCP> by preston@felix.UUCP (Preston Bannister):
> +---------------
> | - You can treat each segment as a seperate address space.  Segments can be
> | moved around in memory as needed.  This is the rather nifty trick Minix uses
> | to efficiently implement fork() without a real MMU.  Since the 68000 has
> | a flat address space, the following program under ST Minix is incredibly
> | inefficient:
>> (...deleted...)
> | On each process switch ST Minix _must_ swap the parent and child data so
> | that the running process is in the same place in the address space.  In PC
> | Minix the process switch only has to change a couple of segment registers.
> | (This _not_ a criticism of ST Minix, as this approach is a necessary
> | function of the 68000 architecture).
> +---------------
> 
> It is NOT necessary.  For example, the Macintosh uses relative addressing
> almost exclusively.  This results in 32K relocatable segments, as the 68000
> uses signed 16-bit displacements.  ST Minix could use the same trick (and
> with some hacking, it could use 64K segments if it wanted to deal with 32K
> of "negative" addresses), in which case your example reduces to exchanging
> the chosen base register, which is done when the process's quantum starts
> anyway.

Almost, but not quite.  The problem is with pointers and the stack
on the 68000.  There are absolute memory addresses embedded in the
stack.  Absolute pointers to within the stack (frame pointers at
least) make the stack not movable.  Return addresses (and function
pointers) in the stack make the pointed to code not movable.

On the other hand, the frame pointers on the 8086 are all offsets
within the stack segment.  If you use only the 8086's "short" calls
then the return addresses are all offsets within the same code
segment.  

You _do_ bring up a good point, as the 68000's relative addressing
mode could be very useful in implementing shared libraries, as done
(surprise, surprise) on the Macintosh.  (Anyone listening?? :-)

(deleted...)
> The Mac uses it so it can rearrange memory as necessary, as
> noted above for the "fork" trick -- otherwise, certain combinations of
> actions could generate lots of holes in memory (open DA, open application,
> close DA -- suddenly there's a sizeable chunk of "dead space" between the
> system heap and the application, where the DA used to be).

Er, I should point out that the Macintosh does NOT have a fork()...

I've never been particularly fond of fork() as a primitive operation,
because it assumes more than is necessary about the architecture of
the machine.  To do fork() efficently, you pretty much have to have
a virtual memory machine.  In the "real" world, most fork() calls
are immediately followed with an exec() call.  The copy of the
process that fork() creates, exec() discards, so why bother making
the copy...
--
Preston L. Bannister
USENET	   :	hplabs!felix!preston
BIX	   :	plb
CompuServe :	71350,3505
GEnie      :	p.bannister