curt@cynic.wimsey.bc.ca (Curt Sampson) (03/09/91)
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.
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?
One last question. Why are the 8086 and 386 stacks variable but the 286
stack fixed?
cjs
curt@cynic.wimsey.bc.ca | "Sometimes it's like a party you go to where
curt@cynic.uucp | there are no lights and everyone is doing
{uunet|ubc-cs}!van-bc!cynic!curt | animal impressions." -Phillip Evans on usenetmd@sco.COM (Michael Davidson) (03/14/91)
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 <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.
paulz@sco.COM (W. Paul Zola) (03/14/91)
In article <3wDiy5w163w@cynic.wimsey.bc.ca> curt@cynic.wimsey.bc.ca (Curt Sampson) writes: }I've got a few questions about stack usage in 286 Xenix. [deleted] }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? No, you don't need to re-compile to change the stack allocation of a '286 binary. The fixhdr(C) command (specifically the -F option) will let you set the stack allocation to any value (within reason) that you like. The hdr(CP) command will let you look at the current stack allocation is. If you want to re-compile, I believe that all you need to do is re-link the objects: the stack size is simply a field in the x.out header. } }One last question. Why are the 8086 and 386 stacks variable but the 286 }stack fixed? A couple of points. First, according to fixhdr(C) and hdr(CP), 8086 model binaries have a fixed stack. (You can modify it with fixhdr -F and see.) Second, the 8086 & '286 stacks are fixed size because they only get one segment, and it's less than 64K. The '386 stack is part of the single '386 data segment - but since '386 segments are 4 gigabtyes, you are going to run out of virtual memory long before you run out of stack. In other words, the fixed size of the '286 & 8086 stacks are artifacts of the Intel architecture. } }cjs } }curt@cynic.wimsey.bc.ca | "Sometimes it's like a party you go to where }curt@cynic.uucp | there are no lights and everyone is doing }{uunet|ubc-cs}!van-bc!cynic!curt | animal impressions." -Phillip Evans on usenet - Paul Zola Software Support Engineer paulz@sco.COM Gotta tend the earth if you want a rose. - Emily Saliers DISCLAIMER: I speak for myself, and not for SCO.