Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!lll-lcc!styx!twg-ap!amdahl!pyramid!decwrl!decvax!tektronix!reed!omen!percival!nerd
From: nerd@percival.UUCP
Newsgroups: comp.os.minix
Subject: Re: Minix and compiler models
Message-ID: <430@percival.UUCP>
Date: Fri, 6-Feb-87 13:39:29 EST
Article-I.D.: percival.430
Posted: Fri Feb  6 13:39:29 1987
Date-Received: Sun, 8-Feb-87 08:29:47 EST
References: <966@ulowell.cs.ulowell.edu> <1565@cit-vax.Caltech.Edu> <500@bobkat.UUCP> <3021@gitpyr.gatech.EDU> <383@dayton.UUCP>
Reply-To: nerd@percival.UUCP (Michael Galassi)
Organization: Percy's UNIX, Portland, OR.
Lines: 20

>>with data starting at the bottom and growing up and the stack at the top
>>and growing down (I think. I don't have the book handy as I write this)

>I always thought stacks grew up.  I think (and hope!) that you've got the
>two reversed!
I don't recal what the stack does on the 80?86 but on the 8080, z80, and
on the 680?0 parts it starts at high memory addresses and grows downwards.
This means that when you 'push' or move xx,-(a7) the stack pointer will
be decremented by the size of the object you are 'pushing' and the object
will then be copied to the location now being pointed to by the stack pointer.
I don't know if I just mis-interpreted 'growing up' or if it is a genuine
error.  The first included peice looks right to me, the heap being dinamicaly
alocated starting low in the segment and growing to higher addresses as
the need arises and the stack doing the oposite 'till they meet and everything
blows up.
-- 
If my employer knew my opinions he would probably look for another engineer.

	Michael Galassi, Frye Electronics, Tigard, OR
	..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!nerd