Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!decwrl!uunet!sco!md From: md@sco.COM (Michael Davidson) Newsgroups: comp.unix.xenix.sco Subject: Re: Stack Usage in 286 Xenix Message-ID: <10774@scolex.sco.COM> Date: 13 Mar 91 19:02:44 GMT References: <3wDiy5w163w@cynic.wimsey.bc.ca> Sender: news@sco.COM Lines: 38 curt@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 or do I have to recompile from >the source? ++ The "hdr" utility will report the current stack size and ++ "fixhdr -F " 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.