From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9907252125.AA14832@clio.rice.edu> Subject: Re: Fixed stack size? To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Sun, 25 Jul 1999 16:25:49 -0600 (CDT) Cc: ams AT ludd DOT luth DOT se, djgpp AT delorie DOT com, dj AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Jul 25, 99 11:29:45 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > On 23 Jul 1999, Martin Str|mberg wrote: > > > Why is the stack size fixed? Can't it be allocated dynamically? Eli Zaretskii replied: > I'm not sure I understand all the subtle aspects of this, but one > problem is that the stack sits between .bss and the heap, so > expanding it would require to move the heap around. (The heap clearly > requires expanding, so it's placed last.) > > DJ, Charles, can you comment on this? Eli has hit it on the head. Under DPMI 0.9 you don't have control of your address space - you can at best allocate a block of memory and take what you have been given - wherever DPMI hands it out. With the sbrk() heap that's not as much of a problem, since the allocated memory doesn't have to be contiguous (except for any single request by itself). With the stack, it has to be contiguous, can't move with respect to the other code/data we have, and expands down - so it must be pre-allocated. I did make a proposal for a dynamic stack once: 1) put the stack below the text/bss area. Access it with wrap at 0xffffxxxx type addresses. This breaks NT support. 2) enable stack limits. This breaks -fomit-frame-pointer 3) use the unixy sbrk. This makes sure the working memory block stays contiguous, but breaks near pointers and many windows systems with small memory. 4) on a stack fault resize the memory, copy the old memory up 64K (or more) in the working memory block, reposition the base of the CS/DS/SS selectors. Locked memory must be tracked, unlocked, relocked (yuk). Given the limitations noone was interested in messing with it.