Re: Parameter Passing Via Registers

mike@vlsivie.tuwien.ac.at (Michael K. Gschwind)
Tue, 30 Apr 1991 14:22:06 GMT

          From comp.compilers

Related articles
Parameter Passing Via Registers lins@apple.com (Chuck Lins) (1991-04-29)
Re: Parameter Passing Via Registers preston@ariel.rice.edu (1991-04-30)
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: mike@vlsivie.tuwien.ac.at (Michael K. Gschwind)
In-Reply-To: lins@apple.com's message of 29 Apr 91 17: 54:04 GMT
Keywords: design, registers, Modula
Organization: Vienna University of Technology
References: <1991Apr30.022048.4539@iecc.cambridge.ma.us>
Date: Tue, 30 Apr 1991 14:22:06 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? ...


Well, there is an easy solution: just generate a list of all variables
used by nested procedures - then you can store these (AND ONLY THESE, they
are bound to be very few) in well-known stack locations. All other
variables can be kept in registers and pronounced dead.


In this set-up, a variable is dead, if


*) it is dead in the procedure
*) and
+) either no nested procedures are called
+) or the varaible is dead upon entry in this
procedure


There are two possibilities to act, if you know a parameter is going to be
referenced in nested procedures. Either push it on the stack upon function
entry or only if you're calling a nested procedure which uses it (You will
need the transitive closure, I guess) - the latter mey be preferable in
some circumstances, but the fromer is easier to implement: Just search the
nested functions and check if the parameter is ever used. If so, reserve a
stack slot and push immediately.


PROCEDURE x( a, b, c ,d : integer) ;
PROCEDURE y ( e,f,g : real);
BEGIN


write (a+f);
END
BEGIN
if (d = 0)
y(a,b,c);
else
write (a);
END


You either do:


_x:
/* a into well-know location, no need to save b,c,d */


st rA, fp+_a
test rD
jne @L1
<call y>
return
@L1: <write>
return


Or:


_x:


test rD
jne @L1
/* a into well-know loc */
st rA, fp+_a
<call y>
return
@L1: <write>
return




      [Can one reference a named parameter in an enclosing procedure? If so, I
      can imagine that would force them onto the stack. -John]


I dunno, but I guess so. Shouldn't be any complication in any case. Maybe
somebody could check out the relevant facts?


Register allocation across all nested functions is *) impossible in Pascal
(since nested procedures may be transmitted via PROCEDURE parameters to
non-related functions) and *) (I guess) not worthwhile in Modula-2 (where
only top-level functions may be assigned to procedure-type variables -
thus you can have a fall-back strategy for all top-level functions and
thus restrict register allocation to a top-level function and all its
nested functions) except if used with a global register allocation
algorithm.


BTW, does anybody know about compilers trying to find 'optimal' register
assignment for top-level Modula-2 functions and all nested functions?
Register allocation could probably done quite easily for such a block of
related functions, as the only entry point from without this block is the
top-level function. Thus the compiler knows all the places where the
nested functions are called.


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
--


Post a followup to this message

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