Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucbvax!hplabs!sdcrdcf!ism780c!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: another auto-increment problem
Message-ID: <1312@haddock.ISC.COM>
Date: Mon, 5-Oct-87 12:11:30 EDT
Article-I.D.: haddock.1312
Posted: Mon Oct  5 12:11:30 1987
Date-Received: Fri, 9-Oct-87 00:41:34 EDT
References: <9600@brl-adm.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 24

In article <9600@brl-adm.ARPA> RMRichardson.PA@Xerox.COM (Rich) writes:
>Hmmmm, ...  If one were using a stack as a stack, and not as a "sort
>of managed" array, then I think Henry has the "right" conlusions for
>the "wrong" reasons; which way the items are addressed on the stack
>or whether the stack runs "up" or "down" in memory wouldn't matter.
>
>For a true stack, the items on the stack should be in order of use, ...

Yes, but since most routines need random access to the arguments, a strict
stack implementation would be useless.  Every non-varargs routine would have
to begin with a prolog to pop the stacked arguments into randomly accessible
locations -- probably either machine registers or (for larger arglists) an
array.  Thus, most C implementations avoid this step by storing the args in an
array in the first place.  (Of course, this "array" is "the stack" on PDP-like
machines.)

>Of course, there is a "work around" if the arguments are pushed on the stack
>first argument first; the function can implement its own stack [and copy].

On machines where "the stack" grows upward, one normally saves the address of
the stack pointer before pushing the arguments.  This is equivalent to using a
queue rather than a stack as the argument-parsing structure.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint