Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site omen.UUCP
Path: utzoo!linus!decvax!decwrl!pyramid!hplabs!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: net.micro.pc,net.unix-wizards
Subject: Re: process stack handling on XENIX-286
Message-ID: <300@omen.UUCP>
Date: Sat, 22-Feb-86 16:59:52 EST
Article-I.D.: omen.300
Posted: Sat Feb 22 16:59:52 1986
Date-Received: Wed, 26-Feb-86 04:29:37 EST
References: <13@spdcc.UUCP>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology, Portland
Lines: 29
Xref: linus net.micro.pc:6909 net.unix-wizards:14099

In article <13@spdcc.UUCP> dyer@spdcc.UUCP (Steve Dyer) writes:
>I'm still a bit confused about how a process grows (or blows) its
>stack under XENIX-286.  To be specific, I'm talking about SCO XENIX V
>for the PC/AT.  I can understand why an unprotected machine like the
>808[86] requires stack to be pre-allocated, but it would seem to me
>that the memory protection facilities of the 286 would allow dynamic
>stack growth much like the PDP-11 or VAX families.  Nevertheless, the
>XENIX documentation still alludes to constructs like
>cc -F hex-number-of-stack-size ...
>Is this just a cautious remnant of 8086 compatibility, or is this
>still necessary when running objects on a 286 machine running XENIX, too.

Depends on the memory model one uses.  With SMALL and MEDIUM models,
there is only one data segment.  Since the 286 memory management only
allows segments to grow in ONE direction, you can grow the heap *or*
grow the stack, but not both.

Actually, it's worse than it seems.  Since memory is so cheap these
days, there would be little penalty incurred by omitting the stack
size spec from the "cc" command if Xenix worked according to the
documentation.  The documentation claims that omitting stack size causes
a maximum sized data segment to be allocated, which would allow the
most memory possible for the heap and stack.  Unfortunately, the default
seems to be a small fixed stack.

With large model, the stack segment can be separate, and can grow
dynamically.  Unfortunately, the large model is still too buggy to be
generally useful.  Now that the 386 is the rage, we may never see a
reasonably debugged large model 286 compiler.