il2 3.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293
  1. .NH 2
  2. Parameters and local variables.
  3. .PP
  4. In the EM calling sequence, the calling procedure
  5. pushes its parameters on the stack
  6. before doing the CAL.
  7. The called routine first saves some
  8. status information on the stack and then
  9. allocates space for its own locals
  10. (also on the stack).
  11. Usually, one special purpose register,
  12. the Local Base (LB) register,
  13. is used to access both the locals and the
  14. parameters.
  15. If memory is highly segmented,
  16. the stack frames of the caller and the callee
  17. may be allocated in different fragments;
  18. an extra Argument Base (AB) register is used
  19. in this case to access the actual parameters.
  20. See 4.2 of
  21. .[
  22. keizer architecture
  23. .]
  24. for further details.
  25. .PP
  26. If a procedure call is expanded in line,
  27. there are two problems:
  28. .IP 1. 3
  29. No stack frame will be allocated for the called procedure;
  30. we must find another place to put its locals.
  31. .IP 2.
  32. The LB register cannot be used to access the actual
  33. parameters;
  34. as the CAL instruction is deleted, the LB will
  35. still point to the local base of the \fIcalling\fR procedure.
  36. .LP
  37. The local variables of the called procedure will
  38. be put in the stack frame of the calling procedure,
  39. just after its own locals.
  40. The size of the stack frame of the
  41. calling procedure will be increased
  42. during its entire lifetime.
  43. Therefore our model will allow a
  44. limit to be set on the number of bytes
  45. for locals that the called procedure may have
  46. (see next section).
  47. .PP
  48. There are several alternatives to access the parameters.
  49. An actual parameter may be any auxiliary expression,
  50. which we will refer to as
  51. the \fIactual parameter expression\fR.
  52. The value of this expression is stored
  53. in a location on the stack (see above),
  54. the \fIparameter location\fR.
  55. .sp 0
  56. The alternatives for accessing parameters are:
  57. .IP -
  58. save the value of the stackpointer at the point of the CAL
  59. in a temporary variable X;
  60. this variable can be used to simulate the AB register, i.e.
  61. parameter locations are accessed via an offset to
  62. the value of X.
  63. .IP -
  64. create a new temporary local variable T for
  65. the parameter (in the stack frame of the caller);
  66. every access to the parameter location must be changed
  67. into an access to T.
  68. .IP -
  69. do not evaluate the actual parameter expression before the call;
  70. instead, substitute this expression for every use of the
  71. parameter location.
  72. .LP
  73. The first method may be expensive if X is not
  74. put in a register.
  75. We will not use this method.
  76. The time required to evaluate and access the
  77. parameters when the second method is used
  78. will not differ much from the normal
  79. calling sequence (i.e. not in line call).
  80. It is not expensive, but there are no
  81. extra savings either.
  82. The third method is essentially the 'by name'
  83. parameter mechanism of Algol60.
  84. If the actual parameter is just a numeric constant,
  85. it is advantageous to use it.
  86. Yet, there are several circumstances
  87. under which it cannot or should not be used.
  88. We will deal with this in the next section.
  89. .sp 0
  90. In general we will use the third method,
  91. if it is possible and desirable.
  92. Such parameters will be called \fIin line parameters\fR.
  93. In all other cases we will use the second method.