清华大学：《编译原理》课程教学资源_（英文译文）Chapter 7.4 Dynamic Memory

COMPILER CONSTRUCTION Principles and practice Kenneth C. louden

COMPILER CONSTRUCTION Principles and Practice Kenneth C. Louden

7. Runtime environments PART TWO

7. Runtime Environments PART TWO

Contents Part one 7. 1 Memory Organization During Program Execution 7. 2 Fully static Runtime Environments 7. 3 Stack-Based Runtime environments Part two 7.4 Dynamic Memory 7.5 Parameter Passing Mechanisms 7.6A Runtime Environment for the TINY Language

Contents Part One 7.1 Memory Organization During Program Execution 7.2 Fully Static Runtime Environments 7.3 Stack-Based Runtime Environments Part Two 7.4 Dynamic Memory 7.5 Parameter Passing Mechanisms 7.6 A Runtime Environment for the TINY Language

7.4 Dynamic Memory

7.4 Dynamic Memory

7.4.1 Fully dynamic runtime Environments

7.4.1 Fully Dynamic Runtime Environments

a stack-based environment will result in a dangling reference when the procedure is exited if a local variable in a procedure can be returned to the caller The simplest example: Int* dangle(void) f int x; return &x Where. the address of a local variable is returned An assignment addr= dangle( now cause addr to point to an unsafe location in the activation stack

• A stack-based environment will result in a dangling reference when the procedure is exited if a local variable in a procedure can be returned to the caller The simplest example: Int * dangle(void) { int x; return &x;} Where, the address of a local variable is returned. • An assignment addr = dangle( ) now cause addr to point to an unsafe location in the activation stack

A somewhat more complex instance of a dangling reference occurs if a local function can be returned by a all Typedef int(* proc)(void) Proc g(int x) fint f( void)/*illegal local function*/ freturn x; return f; mair proc C, g(2); printf( % dn, cO); /*should print 2*/ return 0

• A somewhat more complex instance of a dangling reference occurs if a local function can be returned by a call Typedef int(* proc)(void); Proc g(int x) {int f(void) /*illegal local function*/ {return x;} return f;} main() { proc c; c= g(2); printf(“%d\n ”,c());/* should print 2*/ return 0; }

Of course, C language avoids the above problem by prohibiting local procedure Other languages like Mudula-2, which have local procedures as well as procedure variables, parameters, and returned values, must state a special rule that makes such program erroneous In the functional programming languages, such as lisp and ml. the functions must be able to be locally defined passed as parameters, and returned as results

• Of course, C language avoids the above problem by prohibiting local procedure • Other languages, like Mudula-2, which have local procedures as well as procedure variables, parameters, and returned values, must state a special rule that makes such program erroneous • In the functional programming languages, such as LISP and ML, the functions must be able to be locally defined, passed as parameters, and returned as results

Thus a stack-based runtime environment is inadequate, and a more general form of environment is required, called Fully dynamic Environment In fully dynamic environment, the basic structure of activation record remains the same The space must be allocated for parameters and local variables. and there is still a need for control and access link When control is returned to the caller the exited activation record remains in memory, to be de-allocated at some later time

• Thus, a stack-based runtime environment is inadequate, and a more general form of environment is required, called Fully Dynamic Environment • In fully dynamic environment, the basic structure of activation record remains the same: – The space must be allocated for parameters and local variables, and there is still a need for control and access links • When control is returned to the caller, the exited activation record remains in memory, to be de-allocated at some later time

7.4.2 Dynamic Memory in Obiect-Oriented Languages

7.4.2 Dynamic Memory in Object-Oriented Languages