Re: Parameter Passing Via Registers

Chuck Lins <lins@apple.com> writes:


>Does anyone know how nested procedures affect the ability to pass parameters
>via registers? If there was no up-level access everything would work fine,
>but with this facility you get all sorts of problems. Uplevel access would
>also seem to affect dataflow analysis (the compiler could think that a
>variable is 'dead' when in reality it's going to get accessed by a nested
>local procedure.


One approach would be to pass the first few parameters in registers.
However, in the called routine, it may be necessary to store the
parameters on the stack, in standard locations.


Imagine we have 3 procedures: A, B, and C, where C is nested inside B.
When A calls B, it can pass (say) the first 4 suitable arguments in
registers (where suitable means not a record or array). When C is
compiled (it's compiled before B, since it's nested), we record which of
B's parameters and variables are referenced. For each uplevel reference,
we assume that the values are in some standard place on the stack. When
compiling B, we must leave space on the stack for all the parameters.
When we see a call to C, we know which variables and parameters might be
accessed in C, and must emit code to store any "enregistered" variables
into their home locations on the stack. Note that we must also recognize
the effects of any procedures nested within C.


The above version is "flow-insensitive" analysis, in that we assume that
any reference can be reached and we don't bother about noticing whether
DEFs come before USEs. It sounds slightly hairy, but really it's just
setting a couple of flags per variable in the symbol table, and then
following conventions while generating code.


A more precise version would be "flow-sensitive". Here we do a little
more work to recognize that a variable is always DEF'd before USE, and is
therefore dead.


This is all pretty informal and will take some effort to fill out the
details. We're (probably) saved from the effort of complete call graph
construction and interprocedural analysis by the fact that we're
considering only lexically scoped procedures, without first-class
procedures.


Preston Briggs
--

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