Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!okstate!uokmax!rmtodd
From: rmtodd@uokmax.UUCP
Newsgroups: comp.os.minix
Subject: Re: Minix and compiler models
Message-ID: <445@uokmax.UUCP>
Date: Sat, 7-Feb-87 21:47:12 EST
Article-I.D.: uokmax.445
Posted: Sat Feb  7 21:47:12 1987
Date-Received: Sun, 8-Feb-87 08:09:02 EST
References: <966@ulowell.cs.ulowell.edu> <1565@cit-vax.Caltech.Edu> <264@hqda-ai.UUCP>
Organization: University of Oklahoma, Norman, OK
Lines: 45
Summary: It's a tradeoff -- large data or swapping

In article <264@hqda-ai.UUCP>, merlin@hqda-ai.UUCP (David S. Hayes) writes:
>      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?
The problems with relocating data segments about only arise if your
data+stack space is greater than 64K.  If your program is in one of the two
standard models MINIX apparently supports (code+data+stack in 64K, or "split
I and D" 64Kcode, 64K data+stack), then all you need to shift about the data
section is to change DS and SS to point to the segment's new location.
Assuming the program isn't doing any clever assembly-language tricks in
directly referencing the DS and SS registers, the program should still work.
In effect, the DS and SS registers are acting as the segment-mapping
registers of 286 protected mode and giving us (for these size programs) much
the same capability.
What all this really means is that on the XT you can't extend MINIX to do
both swapping/process moving/etc. AND large data or code segments.  On the
AT you could do both, but on the XT you'll have to choose which one you
want.  Frankly, with only 640K in an XT I don't think large code/data
programs are too feasible in a multitasking environment anyway, especially
if you won't be able to swap.
As for trading compatibility off for capability, well, if you want to use
large code or data on your AT, you'll have to trade away compatibility to
some extent.  But if care is taken to write the new software (e.g the swapper)
with appropriate #ifdefs, it should be possible to have the same source code
on both XT and AT (just stick in, say, #define AT_LARGE_MODEL if you want it).
Programs written under the new "large" AT system may end up too big to port
to the XT, but then the same may be true of programs written on Amiga/ST/etc.
(if and when MINIX is available for those machines).
___________________________________________________________________________
      "You should be very careful when getting a second-hand space-ship.
They can be very unreliable." -- Vila Restal
___________________________________________________________________________
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd