Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!ddl
From: ddl@husc6.UUCP
Newsgroups: comp.os.minix
Subject: Re: Minix and compiler models
Message-ID: <1151@husc6.UUCP>
Date: Mon, 2-Feb-87 12:29:38 EST
Article-I.D.: husc6.1151
Posted: Mon Feb  2 12:29:38 1987
Date-Received: Tue, 3-Feb-87 03:36:38 EST
References: <966@ulowell.cs.ulowell.edu> <1565@cit-vax.Caltech.Edu> <500@bobkat.UUCP>
Organization: Harvard University, Cambridge MA
Lines: 19

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:
MINIX may well support code, data, stack, and even more.  Just because C can't
hack it...  There are also ways to use more memory while still preserving
fork() semantics and swapability.  In OS I implememted two "extended"
memory schemes:  A process usually starts out life with es=ds=ss.  There
are system calls to allocate additional segments which are assigned
descriptors (you know, small non-negative integers...) and a call to
set your segment registers to use this memory.  This all works without
giving up fork() and swapping because processes know only about these
descriptors.  For processes that insist on knowing absolute segment
locations there is a call to set "NONSEG" mode and a call to find
out a segment's address.  A non-segmented process will never be moved
in memory and is not allowed to fork().  It is allowed to vfork().

					Dan Lanciani
					ddl@harvard.*