Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Argument Passing in C (Stacks)
Message-ID: <1988Oct9.214607.25790@utzoo.uucp>
Organization: U of Toronto Zoology
References: <705.2339B3D8@stjhmc.fidonet.org> <699@wsccs.UUCP> <202@obie.UUCP>
Date: Sun, 9 Oct 88 21:46:07 GMT

In article <202@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes:
>But what about hardware without pre-decrement and post-increment
>addressing?  The Univac 1100 and many derivatives of it, for example.
>Or the IBM 360 family?  With the 360, you usually end up using a
>register for the stack pointer, and using macros [for pop and push.]
>The problem with these macros is that they are not atomic...

What you can do, to avoid this, is to allocate some anonymous temporary
variables in the stack frame and use them instead of pushing and popping
temporary values.  Actually, even the original C compiler, with the pdp11's
hardware stack support, used this approach to a small extent:  the topmost
stack location was always a temporary.  (The significance of this on the
11 was that after a function call, one less parameter had to be popped off
the stack, which was a major win since most functions have few parameters
and the 11 was particularly good at popping two or one (or zero!).)  By
doing this, you can generally avoid stack-pointer movement except as part
of the calling sequence.  It does mean that accessing small offsets from
the stack pointer or frame pointer needs to be efficient, which can
impose some constraints.  (For example, if you're not using a separate
frame pointer, on the 360 the stack must grow downward, since the 360
has positive offsets only.)
-- 
The meek can have the Earth;    |    Henry Spencer at U of Toronto Zoology
the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu