Re: procedures and environments

In a project I was involved with we were concerned about efficent
execution of some small procedures. Design was, as I recall


    -- the caller's environment included a flag "invoked routine is
          now executing in caller's environment" for debug info
          and exception handling
    -- the caller's environment included a fixed size work space that
          invoked routines could use
    -- if the invoked routine found a particular invocation to require
          something that could not be handled while executing in the
          caller's environment (for example, having to invoke another
          procedure) then the invoked routine must allocate/initialize
          an environment for itself before continuing -- an environment
          that would appear to have been created by "normal" procedure
          invocation.
    -- other than debug and exception handling, nothing in the system
          was to be aware/sensitive-to this caller/callee interaction.


So: all procedures provided flag and work space in their environments;
only those procedures that could execute given the work space
constraint and that often completed their function without requiring an
environment were implemented to begin execution in the caller's
environment.


There was no [language-level] support.


dick w


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.
>
>(The need for this comes up in some code compression work we're doing,
>where we'd like to take identical code fragments and abstract them
>into procedures. The problem is that the procedures so created need
>to execute in their caller's environment. This feels like something
>someone must have looked at...)

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