Stack Usage in 286 Xenix

W. Paul Zola paulz at sco.COM
Thu Mar 14 09:44:48 AEST 1991


In article <3wDiy5w163w at cynic.wimsey.bc.ca> 
curt at 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 at cynic.wimsey.bc.ca          | "Sometimes it's like a party you go to where
}curt at 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 at sco.COM 
Gotta tend the earth if you want a rose.  - Emily Saliers
    DISCLAIMER: I speak for myself, and not for SCO.



More information about the Comp.unix.xenix.sco mailing list