Stack Usage in 286 Xenix

[Michael Davidson]

curt at cynic.wimsey.bc.ca (Curt Sampson) writes:

>I've got a few questions about stack usage in 286 Xenix.  Is there any
>way to get an idea of how much stack a program will use other than going
>though it and figureing out how many local variables and function calls
>are going to be used?  I've got a hardcopy manual page for stackuse(CP),
>which is supposed to do this, in my 2.3.2 release, but neither the
>binary itself, its libraries or the manual page is on line.

++ Unfortunately, the answer is "no". Static analysis
++ really can't guarantee to come up with the right answer
++ and stackuse(CP) never really worked which is why it was
++ dropped from the product.

>As well, is there any way to change the default stack allocation of a
>binary, or even tell what it is currently allocated to?  Or am I stuck
>recompling with the cc's -F option?  If I do have to use cc, can I just
>relink the object files with -F <number> or do I have to recompile from
>the source?

++ The "hdr" utility will report the current stack size and
++ "fixhdr -F <newsize>" will let you change it.

>One last question.  Why are the 8086 and 386 stacks variable but the 286
>stack fixed?

++ 386 stacks are "variable" because the 80386 supports virtual
++ memory and large virtual address spaces therefore it is
++ possible to allocate a large region of virtual address space
++ for the stack. As far as I can recall the documentation is
++ misleading when it refers to 8086 stacks as being "variable".
++ In fact 8086 Xenix binaries have fixed size stacks just like
++ 80286 binaries, however on some versions of Xenix for the 8086
++ the stack pointer was always initialised to point to the end
++ of the first 64k data segment - this wasn't really a "variable"
++ stack - just one that was pre-allocated to the maximum possible
++ size.