Run-Time Environements

Transcription

1 Run-Time Environements Martin Sulzmann Martin Sulzmann Run-Time Environements 1 / 21

2 Overview Things to consider Static program code versus dynamic procedure activation. First-order functions (C). Nested procedure declarations (C++/Java). Higher-order functions (OCaml/Haskell/Go). Allocation and deallocation of data objects. Stack versus heap. Martin Sulzmann Run-Time Environements 2 / 21

3 Static versus Dynamic Classification Static = at compile time. Dynamic = at run-time. Stack maintains data local to (procedure call). Layout statically known. Managed automatically by generated code. Heap maintains (dynamic) data that survives between calls. Layout statically not known. Managed dynamically by garbage collector. Martin Sulzmann Run-Time Environements 3 / 21

4 Storage Organization Classification Code area: instructions. Static area: (global) constants. Heap: objects (records, arrays,...). Run-time stack: (procedure) activation records/stack frames. Memory Layout Code Static Data Stack. Heap Martin Sulzmann Run-Time Environements 4 / 21

5 Procedures Example int fib(int n){ int f1, f2; if (n<=1) return 1; f1=fib(n-1); f2=fib(n-2); return f1+f2; } We assume a procedural language with sequential control flow, and return to point after the call. Martin Sulzmann Run-Time Environements 5 / 21

6 Activation Tree Example fib(3) fib(2) fib(1) fib(1) fib(0) Node: procedure activation Child: activation from inside parent Order: Left child finishes before right child begins Life-time: From call to exit Martin Sulzmann Run-Time Environements 6 / 21

7 Control Stack Stack for procedure activation Depth-first left-to-right visit of activation tree. fib(3) fib(2) fib(1) fib(3) fib(2) fib(1) fib(1) fib(0) Where do we store (local) data, scope of declarations, binding of names? Martin Sulzmann Run-Time Environements 7 / 21

8 Activation Records Layout Item on (control) stack. Contains all information for an activation of a procedure. local variables function parameters return address static link dynamic link dynamic link = caller s activation record (where to return after procedure exit) static link = non-local data on stack (how to access variables from some outer scope) Martin Sulzmann Run-Time Environements 8 / 21

9 Variable Access Things to consider Method Variables found in some activation record (ignore heap allocated data). Local variable easy (within current activation record). Non-local variable? Must find proper activation record. Location of a variable represented by (level, relpos). level = level of the lexical scope. relpos = relative position in the activation record. Need protocol to properly access variables based on the information provided. Martin Sulzmann Run-Time Environements 9 / 21

10 Example Mini-Go { x := 1; y := true } Activation record y 1 <-- relative position x NULL <-- return address NULL <-- static link (SL) NULL <-- dynamic link (DL) Martin Sulzmann Run-Time Environements 10 / 21

11 Nested Procedure Declarations Example main () { int i; int c() { return i }; int a(int i) { i = 1; int b( ) { int d( ) { return c( ); }; d(); }; b(); }; i = 2; print a(i); } Martin Sulzmann Run-Time Environements 11 / 21

12 Nested Procedure Declarations (2) Level information Procedure level main 1 c 2 a 2 b 3 d 4 Things to consider Call sequence: a(2) b() d() c() Procedure c has access to variable i. Which i? Where do we find i? Martin Sulzmann Run-Time Environements 12 / 21

13 Initial Stack of activation records main i=2 SL=Null DL=Null Martin Sulzmann Run-Time Environements 13 / 21

14 Call a(2) Stack of activation records a(2) // i=1! i=1 SL=main DL=main main i=2 SL=Null DL=Null Martin Sulzmann Run-Time Environements 14 / 21

15 Call b() Stack of activation records b() SL=a DL=a a(2) // i=1! i=1 SL=main DL=main main i=2 SL=Null DL=Null Martin Sulzmann Run-Time Environements 15 / 21

16 Call d() Stack of activation records d() SL=b DL=b b() SL=a DL=a a(2) // i=1! i=1 SL=main DL=main main i=2 SL=Null DL=Null Martin Sulzmann Run-Time Environements 16 / 21

17 Call c() Stack of activation records c() SL=main DL=d d() SL=b DL=b b() SL=a DL=a a(2) // i=1! i=1 SL=main DL=main main i=2 SL=Null DL=Null c = level 2 and d = level 4. Hence k = 2. Follow SL twice. Hence, SL of c equals main. Access i: main (level = 1) and c (level = 2). Follow SL once. Look-up i. Martin Sulzmann Run-Time Environements 17 / 21

18 Call sequence: a(2) b() d() c() Dynamic link main() a(2) b() d() c() Static link main() a(2) b() d() c() Martin Sulzmann Run-Time Environements 18 / 21

19 Managing Activation Records Return sequence Pop current activation record. Follow DL to previous one. Jump to return address and continue. Calling sequence Push new activation record. Set DL to previous one. If level of current block > level of previous block then set SL = SL of the kth previous block (=activation) where k= level of current block - level of previous block (see call c()). Otherwise, set SL = SL of previous block. Martin Sulzmann Run-Time Environements 19 / 21

20 Variable Access Variable access protocol Assume we are within a block at level i and access variable x whose location is represented by (k,relpos). If i=k (x local) then relpos refers to relative position of x in current activation record. If i>k (x global) then we need to follow the SL chain (i-k) times to get to x s activation record. Otherwise (i<k), can never happen. Martin Sulzmann Run-Time Environements 20 / 21

21 Mini-Go Observation No nested procedure declarations. But nested scope. Variables do not need to be declared at the beginning of a block. Introduce distinct variables (renaming!). Variables in main can then be managed by a single activation record. Martin Sulzmann Run-Time Environements 21 / 21