Xref: utzoo comp.unix.questions:30086 comp.unix.internals:2486 comp.unix.programmer:1497 comp.lang.c:37953
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!pacbell.com!att!att!cbnewsm!lfd
From: lfd@cbnewsm.att.com (Lee Derbenwick)
Newsgroups: comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.lang.c
Subject: Re: Unix Stack Frame Questions
Summary: directions vary; some stacks aren't physically laid out
Message-ID: <1991Apr4.230716.21177@cbnewsm.att.com>
Date: 4 Apr 91 23:07:16 GMT
References: <125@epic.epic.com> <GOEHRING.91Mar25113709@gnu.ai.mit.edu> <3465@unisoft.UUCP>
Followup-To: comp.lang.c
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 47

In article <3465@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes:
> /* <GOEHRING.91Mar25113709@gnu.ai.mit.edu> by goehring@gnu.ai.mit.edu
>  * In article <125@epic.epic.com> tan@epic.epic.com (Andy Tan) writes:
>  * 
>  *    1. Is it right to assume that the address of the last automatic
>  *       variable is the bottom of stack frame ?
>  * 
>  * it is not right to assume that there is a stack frame, and some
>  * compilers aren't going to put autos in the frame even if a frame
>  * exists since they can be more cheaply handled with registers.
> 
> If, of course, you have the registers (68K only have so many).
> If there's not a stack frame, how are parameters passed to the
> function...?  And how would you return...?

Even if you know that you have a real stack, some processors grow stacks
up from low address towards higher addresses, and some grow them from
higher addresses toward lower ones.

And some compilers put the first automatic (non-register) variable at the
top of the stack frame, and some put the last auto variable at the top.

So even if you have a real, contiguous stack, knowing the address of one
auto variable doesn't tell you anything portable.

And there are probably some processors that don't maintain a physical
stack at all -- they do the equivalent of a malloc for each stack frame,
and keep a pointer to the calling function's frame.  So while each
function may have a stack frame (or a collection of them, depending how
much can be allocated in one chunk), the actual stack is a linked list.

(Don't laugh!  This is how recursive PL/I procedures worked on the IBM
System/360 and 370; I wouldn't be surprised if the C compilers for their
descendants still do, since IBM had a _very_ standardized calling
sequence for all languages.  Non-recursive procedures generally allocated
their stack frames statically, but all C functions are theoretically
recursive, so I wouldn't expect static allocation to be used except by a
_highly_ optimizing compiler that does inter-procedural control flow
checks.)

All the C language guarantees you is behavior _as if_ there were a
stack.  Regardless of whether you're running it on a Unix system, some
other OS, or bare hardware...

 -- Speaking strictly for myself,
 --   Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ
 --   lfd@cbnewsm.ATT.COM  or  <wherever>!att!cbnewsm!lfd