Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Why my stack grew up and this was wrong
Message-ID: <11336@pt.cs.cmu.edu>
Date: 8 Dec 90 21:06:13 GMT
References: <7298@uklirb.informatik.uni-kl.de>
Organization: Carnegie Mellon Computer Science or maybe Robotics Institute
Lines: 26


In article <7298@uklirb.informatik.uni-kl.de> 
	kirchner@informatik.uni-kl.de (Reinhard Kirchner) writes:
>From the operating system point of view the stack my grow in either
>direction, there is no preference ( I think ). Detection of overflow
>my be simpler in one direction, but thats all.
>Stack and heap should always grow in opposite directions, so you
>can allocate one pool of memory for both without any fixed size for one.

This was completely correct, in the days of small, flat address
spaces. With the advent of large virtual address spaces, it became
reasonable to carve out huge regions as segments, and the stack and
heap could be in separate segments. With the advent of thread-style
OSes, there are now multiple stacks in the same address space.

Further, we used to use software overflow checks. The correct answer
now is to have the OS put invalid pages at appropriate places. This
is a genuine improvement: it has perfect coverage (unlike some of the
old software schemes), and it should have no runtime overhead.

This means that the "correct" way to run a stack is completely
determined by the addressing modes and the procedure call protocol.
I believe that Robert Firth wants them to grow upward, but then, he
knows more about procedure call protocols than I do.
-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon