Procedure Environments & ActivationsStack-based Runtime EnvironmentsAddressing variables in the FrameOther Information in Each FrameExecution of Louden’s ExampleDynamically Computed Environments and Stack AllocationProcedure Environments & Activations•We’ll have another take on what makes up a closure.•Louden discusses the fully static environment model of Fortran77. Such a primitive procedure activation model associates preallocated storage with each procedure.•Our primary concern will be Stack-based runtime environments.Stack-based Runtime Environments•The activation records (frames) are maintained in a stack. The current procedure’s activation information is recorded in the stack top. It’s caller’s activation is the next element in the stack, and so forth. Below the top element, which corresponds to the active procedure, the stack is a LIFO list of all suspended calls.•It is common to refer to the current frame pointer or current activation record pointer as the environment pointer, or ep.•Louden refers to the activation stack pointer, which I call the dynamic chain pointer, the control link.•In compiled languages, the code for a function is typically allocated in static storage. The address of a function is referred to as its instruction pointer, or ip.Addressing variables in the Frame•In a statically compiled language, as each variable declaration is encountered in a procedure definition, all the relevant attributes of that variable are known. These include its–type–size–offset in the activation record•Thus, in a compiled language, we do not need to keep track of variable names at runtime.Other Information in Each Frame•The control link must appear in the stack so that we can restore our referencing environment (the environment pointer) after completion of the call.•The return address (address of the instruction following the call instruction) in the calling context must be stored so we can restore our execution state after completion of the call.•The address of the most recently created frame for the statically enclosing environment must be stored so we can get access to nonlocal data. Louden calls this the access link(Note, this is not necessary in C, Java, and C++ because there is no way to define a function whose nonlocal referencing environment is anything other than the global environment.)Execution of Louden’s Exampleprocedure lastex is procedure p(n:integer) isprocedure show isbegin if n > 0 then p(n-1); end if; put(n); new_line; end show; begin -- p show; end p;begin -- lastex p(1);end lastex;p: < ,ip1>...epcontrol linkaccess linkshow:< ,ip2>n:1control linkaccess linkcontrol linkaccess linkn:0show:< ,ip2>control linkaccess linkDynamically Computed Environments and Stack Allocation•Consider the following scheme code:(define (makecount) ;; define a function, makecount (let ((x 0)) ;; create a block containing x (lambda () (set! x (+ x 1)) ;; make a function value))•This can be used as follows:(set! mycount (makecount)) ;; mycount is the function value ;; returned by makecount(mycount) ;; returns 1(mycount) ;; returns 2(mycount) ;; returns 3•Now let’s draw the activation record structures corresponding to all of this.•We see that a simple stack cannot be employed, because an ep to the makecount activation persists in its result function after makecount’s activation is terminated.•Clearly activation records in such a dynamic language must be allocated on the heap and garbage