|[2 earlier articles]|
|Re: Parameter Passing Via Registers email@example.com (1991-04-30)|
|Re: Parameter Passing Via Registers firstname.lastname@example.org (A. V. Le Blanc) (1991-04-30)|
|Re: Parameter Passing Via Registers email@example.com (1991-04-30)|
|Re: Parameter Passing Via Registers firstname.lastname@example.org (Rob MacLachlan) (1991-05-01)|
|Re: Parameter Passing Via Registers email@example.com (1991-05-02)|
|Re: Parameter Passing Via Registers firstname.lastname@example.org (1991-04-30)|
|Re: Parameter Passing Via Registers email@example.com (Mario Wolczko) (1991-05-02)|
|Re: Parameter Passing Via Registers firstname.lastname@example.org (Michael K. Gschwind) (1991-05-03)|
|Re: Parameter Passing Via Registers email@example.com (1991-05-07)|
|From:||Mario Wolczko <firstname.lastname@example.org>|
|Keywords:||optimize, registers, Pascal, Modula|
|Organization:||Department of Computer Science, University of Manchester|
|Date:||2 May 91 15:17:49 GMT|
In article <1991Apr30.email@example.com>, firstname.lastname@example.org (Chuck Lins) writes:
> Does anyone know how nested procedures affect the ability to pass parameters
> via registers? ...
This is a particularly gruesome problem in languages that have
procedures whose closures are first-class objects, and can outlive
their surrounding context. Smalltalk and Scheme are examples.
In Smalltalk, for example, you can write:
var := [ :x | x + arg].
This returns a "block" (the expression in brackets; similar to a bound
lambda-expression in Scheme) that references the argument in its
enclosing method, despite the block outliving the method invocation.
My Scheme is a little rusty, but I think it would be something like:
(define method (arg)
(lambda (x) (+ x arg)))
The problem here is that the closure for the block/function needs to
reference the activation record for "method", even when control has
returned from "method".
A naive implementation of this is to put every activation in the heap, and
garbage collect dead ones [GR83]. Better is to put activation records on
the stack, and defer conversion to heap form until absolutely necessary
[DS84]. This gets trickier when your activations live in register windows
[Ung87], which is where your question comes in. In the Smalltalk compiler
I'm working on at the moment, one phase of the compiler attempts to locate
variables which are genuinely shared between activations (including
dataflow and liveness analysis), and then allocates a value holder for
them in the heap. Otherwise they're truly local and can go in registers.
I can supply more details if you're interested. It should be a lot
simpler in languages with strict LIFO activations.
[GR83] A. Goldberg, D. Robson, "Smalltalk-80: The Language and its
Implementation," Addison-Wesley, 1983.
[DS84] L. P. Deutsch, A. M. Schiffman, Efficient Implementation of the
Smalltalk-80 System, ACM POPL11, 1984.
[Ung87] D. M. Ungar, The Design and Evaluation of a High Performance
Smalltalk System, MIT Press, 1987.
Dept. of Computer Science Internet: email@example.com
The University uucp: mcsun!ukc!man.cs!mario
Manchester M13 9PL JANET: firstname.lastname@example.org
U.K. Tel: +44-61-275 6146 (FAX: 6236)
Return to the
Search the comp.compilers archives again.