Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcnc!rti-sel!dg_rtp!meissner
From: meissner@dg_rtp.UUCP
Newsgroups: comp.arch
Subject: Re: Stack Growth Direction
Message-ID: <1098@dg_rtp.UUCP>
Date: Thu, 19-Feb-87 10:08:05 EST
Article-I.D.: dg_rtp.1098
Posted: Thu Feb 19 10:08:05 1987
Date-Received: Fri, 20-Feb-87 21:20:08 EST
References: <2249@felix.UUCP> <5356@mimsy.UUCP>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Distribution: world
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 24

In article <5356@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:
> Jim Gilbert writes:
> 
> >Although stacks do grow down on:
> [Long list of Machines]
> 
> >they do grow up on some machines
> [much shorter list of machines]

    While we are at it, the Data General Eclipse (16-bit) and MV/Eclipse
(32-bit) machines grow their stacks upward as well.  This causes two problems
in dealing with UNIX on the MV/Eclipses.  First is all of the programs that
don't use varargs, but still deal with variable argument lists.  Second is
that the sbrk area must grow upwards.  This means you can't in general do
the trick of going the stack down and the heap (sbrk) up.  If the user does
not do a sbrk, but does call malloc, we sbrk the address space, and grow
the heap down & the stack up.  If the user does call sbrk/brk directly,
we reserve a chunk of memory for his/her sbrk-ing, and use the rest as
before.  There are also options for fixing the size of the stack and/or
heap, as well as changing how much memory is reserved for sbrk.
-- 
	Michael Meissner, Data General	Uucp: ...mcnc!rti-sel!dg_rtp!meissner

It is 11pm, do you know what your sendmail and uucico are doing?