123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293 |
- .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.
|