Re: procedures and environments (Andreas Krall)
9 Nov 1999 01:39:36 -0500

          From comp.compilers

Related articles
procedures and environments debray@CS.Arizona.EDU (1999-11-04)
Re: procedures and environments (1999-11-05)
Re: procedures and environments (Max Hailperin) (1999-11-05)
Re: procedures and environments (David L Moore) (1999-11-05)
Re: procedures and environments (1999-11-05)
Re: procedures and environments (1999-11-09)
Re: procedures and environments (1999-11-09)
| List of all articles for this month |

From: (Andreas Krall)
Newsgroups: comp.compilers
Date: 9 Nov 1999 01:39:36 -0500
Organization: Vienna University of Technology, Austria
References: 99-11-028
Keywords: optimize

debray@CS.Arizona.EDU (Saumya K. Debray) writes:
> In most modern programming languages, procedure activations are
> typically associated with their own environments, which means that a
> procedure call involves two distinct actions: (1) the control transfer
> from caller to callee; and (2) the allocation/initialization of the
> callee's environment. Does anyone know of any [language-level]
> proposal to separate these two actions? In other words, a call would
> transfer control to the callee, which could either allocate an
> environment, or---if it chose to not allocate an environment for
> itself---execute in the caller's environment.

I do not know of a language level proposal for separation of these two
actions. But the JavaVM makes a distinction on the byte code level.
For method invocations with environment allocation there exist the
instructions "invokevirtual", "invokeinterface", "invokestatic" and
"invokespecial". These method calls take their arguments from the
stack and allocate a new environment. The corresponding "return" or
"type_return" dealloctes the environment. The instruction "jsr" calls
a subroutine inside a method and has access to all local variables of
the method in which it is embedded. The return address is saved on the
stack and must be saved in a local variable for use of the "ret"
instruction which takes a local variable number as an operand which
contains the return address. The main use of this "jsr-ret" is for the
implementation of finally statments of Java and can be used for code
compression, your required application domain. Using the information
how Java compilers translate finally you could perhaps use Java for
compression putting the reused code into finally statements.

-- Andreas Krall Inst. f. Computersprachen, TU Wien
tel: (+431) 58801/18511 Argentinierstr. 8/4/1851
fax: (+431) 58801/18598 A-1040 Wien AUSTRIA EUROPE

Post a followup to this message

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