Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!tektronix!uw-beaver!ubc-vision!alberta!calgary!radford
From: radford@calgary.UUCP
Newsgroups: comp.os.minix
Subject: Stack growth
Message-ID: <800@vaxb.calgary.UUCP>
Date: Wed, 11-Feb-87 12:54:07 EST
Article-I.D.: vaxb.800
Posted: Wed Feb 11 12:54:07 1987
Date-Received: Sat, 14-Feb-87 12:42:55 EST
References: <966@ulowell.cs.ulowell.edu> <1565@cit-vax.Caltech.Edu> <1377@cbmvax.cbmvax.cbm.UUCP>
Organization: U. of Calgary, Calgary, Ab.
Lines: 23
Keywords: stacks

In article <1377@cbmvax.cbmvax.cbm.UUCP>, grr@cbmvax.cbm.UUCP (George Robbins) writes:

> >To my knowledge, the PDP-11 was the first machine in which stacks went
> >the "wrong" way (from the "traditional" point of view). Later, people
> >figured out that it made more sense on a 360 for the stacks to go the
> >other way.

> To save beating around the bush, one good reason for having stacks grow
> down is that many architectures do not support signed indexing off registers
> This makes it difficult to access things pushed up on the stack by using
> stack pointer relative addressing...

OK, I'll bite. I've always thought that stacks grow down from the top of
memory because it's more satisfying to always have the first byte of the
program in a fixed location (say 0) than to have the first byte of the
*stack* always in a fixed location.

For example, on a stand-alone PDP 11, the stack grows down from the top of
memory, *wherever that may be*. The program is loaded into low memory, which
is always the same place. So you don't have to re-link all your programs
when you buy more memory.

     Radford Neal