93 lines
3 KiB
Text
93 lines
3 KiB
Text
.NH 2
|
|
Parameters and local variables.
|
|
.PP
|
|
In the EM calling sequence, the calling procedure
|
|
pushes its parameters on the stack
|
|
before doing the CAL.
|
|
The called routine first saves some
|
|
status information on the stack and then
|
|
allocates space for its own locals
|
|
(also on the stack).
|
|
Usually, one special purpose register,
|
|
the Local Base (LB) register,
|
|
is used to access both the locals and the
|
|
parameters.
|
|
If memory is highly segmented,
|
|
the stack frames of the caller and the callee
|
|
may be allocated in different fragments;
|
|
an extra Argument Base (AB) register is used
|
|
in this case to access the actual parameters.
|
|
See 4.2 of
|
|
.[
|
|
keizer architecture
|
|
.]
|
|
for further details.
|
|
.PP
|
|
If a procedure call is expanded in line,
|
|
there are two problems:
|
|
.IP 1. 3
|
|
No stack frame will be allocated for the called procedure;
|
|
we must find another place to put its locals.
|
|
.IP 2.
|
|
The LB register cannot be used to access the actual
|
|
parameters;
|
|
as the CAL instruction is deleted, the LB will
|
|
still point to the local base of the \fIcalling\fR procedure.
|
|
.LP
|
|
The local variables of the called procedure will
|
|
be put in the stack frame of the calling procedure,
|
|
just after its own locals.
|
|
The size of the stack frame of the
|
|
calling procedure will be increased
|
|
during its entire lifetime.
|
|
Therefore our model will allow a
|
|
limit to be set on the number of bytes
|
|
for locals that the called procedure may have
|
|
(see next section).
|
|
.PP
|
|
There are several alternatives to access the parameters.
|
|
An actual parameter may be any auxiliary expression,
|
|
which we will refer to as
|
|
the \fIactual parameter expression\fR.
|
|
The value of this expression is stored
|
|
in a location on the stack (see above),
|
|
the \fIparameter location\fR.
|
|
.sp 0
|
|
The alternatives for accessing parameters are:
|
|
.IP -
|
|
save the value of the stackpointer at the point of the CAL
|
|
in a temporary variable X;
|
|
this variable can be used to simulate the AB register, i.e.
|
|
parameter locations are accessed via an offset to
|
|
the value of X.
|
|
.IP -
|
|
create a new temporary local variable T for
|
|
the parameter (in the stack frame of the caller);
|
|
every access to the parameter location must be changed
|
|
into an access to T.
|
|
.IP -
|
|
do not evaluate the actual parameter expression before the call;
|
|
instead, substitute this expression for every use of the
|
|
parameter location.
|
|
.LP
|
|
The first method may be expensive if X is not
|
|
put in a register.
|
|
We will not use this method.
|
|
The time required to evaluate and access the
|
|
parameters when the second method is used
|
|
will not differ much from the normal
|
|
calling sequence (i.e. not in line call).
|
|
It is not expensive, but there are no
|
|
extra savings either.
|
|
The third method is essentially the 'by name'
|
|
parameter mechanism of Algol60.
|
|
If the actual parameter is just a numeric constant,
|
|
it is advantageous to use it.
|
|
Yet, there are several circumstances
|
|
under which it cannot or should not be used.
|
|
We will deal with this in the next section.
|
|
.sp 0
|
|
In general we will use the third method,
|
|
if it is possible and desirable.
|
|
Such parameters will be called \fIin line parameters\fR.
|
|
In all other cases we will use the second method.
|