Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 ggr 10/28/83; site pyuxbb.UUCP
Path: utzoo!linus!security!genrad!decvax!harpo!floyd!vax135!ariel!hou5f!hou5g!hou5h!eagle!allegra!alice!rabbit!pyuxbb!ggr
From: ggr@pyuxbb.UUCP
Newsgroups: net.lang.c
Subject: Re: var args - (nf)
Message-ID: <230@pyuxbb.UUCP>
Date: Thu, 3-Nov-83 17:37:34 EST
Article-I.D.: pyuxbb.230
Posted: Thu Nov  3 17:37:34 1983
Date-Received: Sat, 5-Nov-83 19:57:21 EST
References: mordor.134 <968@utah-gr.UUCP>
Organization: AT&T Bell Laboratories, Piscataway
Lines: 20


  > Re: S-1 upward growing stack.
  > 
  > (Of course, this depends on your hardware cooperating.)  The way I would
  > solve the problem would be to have the frame pointer point to  the first
  > argument (or, perhaps, to the word above the first argument), so that args
  > would be at (constant) negative offsets form the frame pointer, and local
  > vars would be at positive offsets.  Then you don't have a problem with
  > getting the wrong arg when called with the wrong number of them.
  > 
  > =Spencer

Yes, I can testify that this scheme works fine.  I used negative offsets
for arguments in the Data General Nova/Eclipse C compiler I wrote,
since their hardware stacks also grew upward.

With appropriate modification of /usr/include/varargs.h, functions that
expect a variable number of arguments (and use varargs, of course)
will even work with this "unconventional" stack structure.

			=== Guy Riddle == AT&T Bell Laboratories, Piscataway ===