Re: Parameter Passing Via Registers

Mario Wolczko <mario@cs.man.ac.uk>
2 May 91 15:17:49 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: Parameter Passing Via Registers mike@taumet.com (1991-04-30)
Re: Parameter Passing Via Registers zlsiial@cms.manchester-computing-centre.ac.uk (A. V. Le Blanc) (1991-04-30)
Re: Parameter Passing Via Registers mike@yalla.tuwien.ac.at (1991-04-30)
Re: Parameter Passing Via Registers ram+@cs.cmu.edu (Rob MacLachlan) (1991-05-01)
Re: Parameter Passing Via Registers mauney@eos.ncsu.edu (1991-05-02)
Re: Parameter Passing Via Registers mike@vlsivie.tuwien.ac.at (1991-04-30)
Re: Parameter Passing Via Registers mario@cs.man.ac.uk (Mario Wolczko) (1991-05-02)
Re: Parameter Passing Via Registers mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (1991-05-03)
Re: Parameter Passing Via Registers mauney@eos.ncsu.edu (1991-05-07)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Mario Wolczko <mario@cs.man.ac.uk>
Keywords: optimize, registers, Pascal, Modula
Organization: Department of Computer Science, University of Manchester
References: <1991Apr30.022048.4539@iecc.cambridge.ma.us>
Date: 2 May 91 15:17:49 GMT

In article <1991Apr30.022048.4539@iecc.cambridge.ma.us>, lins@apple.com (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:
method: arg
...
var := [ :x | x + arg].
^var
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.


Mario Wolczko


[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: mario@cs.man.ac.uk
The University uucp: mcsun!ukc!man.cs!mario
Manchester M13 9PL JANET: mario@uk.ac.man.cs
U.K. Tel: +44-61-275 6146 (FAX: 6236)
--


Post a followup to this message

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