[comp.lang.c] MSC and stack manipulation

gp@picuxa.UUCP (Greg Pasquariello X1190) (10/05/87)

Here is a question for anyone who cares to throw his stack in the ring.
When MSC 4.0 calls a function, it subtracts the amount of space needed
by local variables from the stack.  Why?  The 80x86 instructions subtract
two bytes from SP when a push is done anyway.  Therefore the MSC function
calls leave an unused gap in the stack equal to the count of bytes 
required by local variables.

	For example:

		func FOO1:	SP = 128
				CALL FOO2

		func FOO2(char, char):
				SP = 126
				BP = SP
				SP = SP - 2	/* WHY??? */
				.
				.
				.
				SP = BP
				RETURN

Unless I'm missing something, the SP = SP - 2 statement points the stack
two bytes below the last push.  Therefor the next push will put the value
of the register (whatever it may be) two bytes below the previous push
thus leaving a gap in the stack of two bytes.


Any answers will be appreciated.


Oh yeah, no flames please, if this sounds like a pathetically stupid 
question :-)

franka@mmintl.UUCP (Frank Adams) (10/07/87)

In article <325@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes:
>Here is a question for anyone who cares to throw his stack in the ring.
>When MSC 4.0 calls a function, it subtracts the amount of space needed
>by local variables from the stack.  Why?  The 80x86 instructions subtract
>two bytes from SP when a push is done anyway.

Because the program, in general, may use that local variable any number of
times.  Thus, when a value is put in it, it is *stored*, not pushed.  Also,
there may be other locals, and the order in which they are used may be
arbitrary.

So the routine has to adjust SP to leave space for the local variables.

It would be a possible optimization, if most or all of the locals had
initialization expressions, to compute and push them for the initial
allocation.  However, this is not necessarily an optimization.  I don't have
access to 8086 timing specs at the moment, but on many machines, stores take
less time than pushes, so for some number of arguments, the subtract and
store methodology is a win.

Again; the space left by the subtraction is used later in the program.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (10/10/87)

Nobody seems to have risen to this, so I'll speculate a possibility.

In article <325@picuxa.UUCP> gp@picuxa.UUCP (Greg Pasquariello X1190) writes:
>....  Therefor the next push will put the value
>of the register (whatever it may be) two bytes below the previous push
>thus leaving a gap in the stack of two bytes.

The PDP-11 compiler did this.  The observation was that there were a lot of
one- and two-argument functions being called.  Leaving a gap essentially
pre-allocated the space for one argument, making the calling sequence shorter
-- the stack adjustment upon return from a one-argument function is no longer
required.  Also, on the PDP-11, the two-argument case was also optimized,
since a shorter (one word) instruction could clean up the stack pointer.

MSC may be doing something similar.
-- 
-- Greg Noel, NCR Rancho Bernardo     Greg.Noel@SanDiego.NCR.COM