Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!oliveb!intelca!mipos3!kds
From: kds@mipos3.intel.com (Ken Shoemaker)
Newsgroups: comp.os.minix,comp.sys.ibm.pc,comp.sys.intel
Subject: Re: protected mode 80286 questions
Message-ID: <1147@mipos3.intel.com>
Date: Mon, 12-Oct-87 15:42:42 EDT
Article-I.D.: mipos3.1147
Posted: Mon Oct 12 15:42:42 1987
Date-Received: Wed, 14-Oct-87 05:07:50 EDT
References: <93@rocksvax.UUCP>
Reply-To: kds@mipos3.UUCP (Ken Shoemaker ~)
Organization: Intel, Santa Clara, CA
Lines: 29
Xref: mnetor comp.os.minix:1875 comp.sys.ibm.pc:8995 comp.sys.intel:372

well, maybe I'm dense, but I don't quite understand the problem.  There is no
reason why you couldn't just put the stack and data in the same segment with
the same attributes.  Thus, if you pop off the top of the segment, you will
get a segment limit violation.  Note that this doesn't use the grow down
segment type for the stack.  The real problem is if you can't determine
the maximum size of the stack, then you have the possibility of your stack
growing into your data.  An option to take care of this is to put the stack
below the data, so that if the stack tries to grow too large you get a
segment violation.  Of course, if you try to pop too much, then you start
using your data area as your stack, and strange things can happen, but aren't
these usually program bugs?  At least, in either case, you will stay within
your limits, because if you don't you will get a trap.

Also, I don't really think that using 32-bit segments will solve your problems
if both your data and stack can fit within the same 16-bit segment, which is
what you want to do, since you want to allocate even less than 64k for the
segment.  The thing that the 386 provides you here is that you can seperate
your stack and heap by lots of empty space in virtual memory using the
page hardware to use a minimum of physical memory but allowing for simple
grows of the stack or heap, and to cause traps if either get too close to
each other.
-- 
The above views are personal.

its another of those basic things you're never taught at school...

Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California
uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds
csnet/arpanet: kds@mipos3hourlls ta