dyer@spdcc.UUCP (Steve Dyer) (02/20/86)
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.
Thanks,
--
Steve Dyer
dyer@harvard.HARVARD.EDU
{bbncca,bbnccv,harvard}!spdcc!dyergemini@homxb.UUCP (Rick Richardson) (02/21/86)
I can't be sure about XENIX, but Venix/286 also has loader options for
specifying the stack size. You don't need them, but if you do use them,
you end up with a faster executing load module, at the expense of being
able to grow the stack.
Rick Richardson, PC Research, Inc. (201) 922-1134
..!ihnp4!houxm!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!!!caf@omen.UUCP (Chuck Forsberg WA7KGX) (02/23/86)
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.
dyer@spdcc.UUCP (Steve Dyer) (02/24/86)
In article <300@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > 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... > > 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. > Wouldn't it be possible under a small model to allocate TWO data segments which would ultimately be mapped to the same address ranges, but one would be for the heap and grow upwards, while the stack segment grew downwards? If a small model program produced by a compiler never touches the segment registers and uses only 16 bit addresses, it seems to me that this should work; I guess the loader and the kernel would have to be changed to support this. Are there any holes in this scheme? -- Steve Dyer dyer@harvard.HARVARD.EDU {bbncca,bbnccv,harvard}!spdcc!dyer