Re: Parameter Passing Via Registers

Dr. Jon Mauney writes:
>Most of the discussion has mentioned ways of forcing parameters passed in
>registers onto the stack for non-local reference. Note that it is not
>strictly necessary for such parameters to be on the stack. Since the
>references occur within internal functions, code could be compiled to use
>the value in the register. You would have to change the calling sequence
>so as to preserve the register, but you have control of both sides of the
>call, so that is possible. Conceivably, this could be done even if the
>procedure is passed as a parameter -- just make sure the register value is
>part of the closure that you pass.
>
>I'm not claiming it's worth the trouble...


It IS worth the trouble if you're doing global register allocation or at
least register allocation relative to a top-level function and its nested
procedures. IT IS (probably) NOT worth it if you're only trying to prevent
forcing parameters on the stack because they are used in some nested
procedures. You might of course find a simple algorithm which would not
cost much, but to be really effective, you'd probably have to do extensive
data flow analysis. Parameters used in nested procedures are (probably)
too rare warrant such extensive data flow analysis. But if you're doing
data flow analysis anyway, you'll probably get it for free. You can then
probably apply the strategy adopted for local variables used in nested
functions to parameters as well (or vice versa ;-).


You write that "this could be done even if the procedure is passed as a
parameter". This is not correct in the general case, and the case you line
out, namely "just make sure the register value is part of the closure that
you pass", is not feasable. Procedures passed as parameters can be called
from just about any context, e.g., library functions, separately compiled
modules etc., thus you cannot change the calling sequence. In the case of
functions passed as parameters/procedure typed variables, you always have
to have a standardized calling sequence.


You could of course always store the calling conventions of every function
in a library or external module in a data base, but what do you do if you
are PascalWorkstations, Inc. and your shared library has a bug? You have
to keep the same calling conventions for a function 'x' once you have sold
a single copy of a shared library containing it, or all programs linked
with the new, improved shared library, but compiled with the old one
(i.e., all commercial programs sold for your workstation) will no longer
work!


Modula-2 is much easier here: if you want to do aggressive register
allocation, you can optimize all top-level functions + their nested
functions, while retaining a consistent calling convention for top-level
functions, which are the only functions which may be assigned to
procedure-typed variables.


bye,
mike




Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at || mike@vlsivie.uucp
Voice: (++43).1.58801 8144 || Fax: (++43).1.569697
--

Return to the comp.compilers page.
Search the comp.compilers archives again.