🚀 go-pugleaf

Dick Menninger <Dick.Menninger@daytonoh.attgis.com> writes:

>> ==========Michael Elizabeth Chastain, 11/25/95==========
>
>> I say 'may have to' because every processor I know can implement
>> variable-sized stack frames by subtracting an appropriate value from
>> the stack pointer at the appropriate time.  But what about processors I
>> don't know about?  Are there truly any processors in use which don't
>> support subtracting a computed value from the stack pointer?
>
>Subtract implies stack direction.  There have been machines with
>stacks that increased in address instead of decreased in address.

Oh, in that case, you just subtract a negative number ;-)

>Also, how about the case of several of these in one stack frame.
>The "start" (i.e., address) of some is affected by the size of others
>rather than just being an offset into the stack frame from the frame
>pointer.  That makes the solution messier to do and starts favoring
>the various heap schemes for this as preserving fixed frame offsets
>is usually a very good thing to do.

If that is a problem, you can use an extra level of indirection so that
each variable gets a unique offset into the stack.  But you should
still allocate the memory on the stack if you can, since it will be
more efficient that way. 

For example, given the following source code,

	void foo(int n) {
		char bar[n];
		char baz[n];
		quux(n, bar, baz);
	}

the compiler could generate code equivalent to

	void foo(int n) {
		char *bar_ptr = alloca(n);
		char *baz_ptr = alloca(n);
		quux(n, bar_ptr, baz_ptr);
	}

where `alloca()' could be a compiler builtin that just decremented or
incremented the stack pointer.  Now `bar_ptr' and `baz_ptr' can both
have fixed offsets relative to the frame pointer.  In fact since
`bar_ptr' and `baz_ptr' are compiler-introduced variables whose address
can never be taken (taking the address of `bar' gives the *value* of
`bar_ptr'), if there are enough registers available they could be
allocated in registers rather than on the stack.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
I will have little or no net access from Nov 30 until Dec 25.
Please email me a copy of any follow-ups.

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]