Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!sundc!hqda-ai!merlin
From: merlin@hqda-ai.UUCP (David S. Hayes)
Newsgroups: comp.os.minix
Subject: Re: Minix and compiler models
Message-ID: <264@hqda-ai.UUCP>
Date: Thu, 5-Feb-87 16:31:59 EST
Article-I.D.: hqda-ai.264
Posted: Thu Feb  5 16:31:59 1987
Date-Received: Sat, 7-Feb-87 15:29:06 EST
References: <966@ulowell.cs.ulowell.edu> <1565@cit-vax.Caltech.Edu> <500@bobkat.UUCP>
Organization: Army AI Center, Pentagon
Lines: 70
Summary: MINIX uses micro-sized memory models

In article <500@bobkat.UUCP>, m5d@bobkat.UUCP (Mike McNally ) writes:
-> I have BIG BIG problems believing that Minix allows separate code,
-> data, and stack segments.  This is NOT small model, at least not as
-> defined by Intel.  In fact, it's no model at all:
-> 
-> 	Small:	
-> 		one code seg, one data seg (incl. data, stack, and constants)
-> 	Compact: 
-> 		code, data, stack, and "memory"
-> 	Medium: 
-> 		one code seg. per module, only one each data, stack, "memory"
-> 	Large: 
-> 		one code seg & one data seg per module, one stack and 
->         one "memory"

     MINIX normally uses CS == SS == DS, putting code, data, and
stack in the same 64K chunk.  Obviously not very suitable.  In the
"separate I and D space" model, CS is reassigned, but SS == DS.

-> In all the models except "small" (or 8085 model, which is almost the
-> same for the purposes of this discussion), pointers MUST be 32 bits.
-> Why?  Because otherwise the location referenced by the pointer cannot
-> be determined.  Consider the C statemnt
-> 
->     x = *p;
-> 
-> where "p" is a 16 bit pointer.  Which segment register should be used
-> to form the address?  Well, in "small" model we only have two choices,
-> so this MUST be a reference within the data segment, either to static
-> dtata, something on the stack, or a constant.
     [ deleted ]
-> Why do I think it's important that Minix use 16 bit pointers?  Because
-> it seems to me that having hard (i.e. 32 bit non-relocatable pointers)
-> pointers makes a correct implementation of fork() impossible.  
     [example deleted] 
-> If pointers are 16 bits long, this works fine; the child process
-> refers to its own private copy of the [data] space.
-> BUT, if pointers are 32 bits, then a segment base address exists
-> in the value of "p".  There is no possible way that the
-> operating system can find this absolute address and change it
-> during the fork().  The new process will have a different DS,
-> but the reference through *p will in both processes refer to
-> the exact same memory location.
-> 
-> The problem of absolute pointers also arises if process swapping is to
-> be considered.

     A very fine analysis, pointing out a problem I had not
worried about previously.  Of course, I'm running on a 286-based
PC/AT.

     Within the 286 protected mode, each process may have its own
set of segments.  The operating system may map each any process
segment number into any physical location it wants.  References to
unmapped segments elicit a trap to the OS.

     A swapping, shared-text-space memory allocation scheme is
only practical on machines that support some form of memory
protection.  While we may be able to put this capability into
MINIX for the AT, the PC/XT and its look-alikes will be left
behind.  This is vaguely distrubing to me...  Will we end up
giving away the standardization that Andy Tanenbaum has given us?
How much compatibility should we be willing to trade for the sake
of increased capability?

-- 
	David S. Hayes, The Merlin of Avalon
	PhoneNet:	(202) 694-6900
	ARPA:		merlin%hqda-ai.uucp@smoke.brl.mil
	UUCP:		...!seismo!sundc!hqda-ai!merlin