INF5110 – Compiler Construction Run-time environments Spring 2016 1 / 92
Outline 1. Run-time environments Intro Static layout Stack-based runtime environments Stack-based RTE with nested procedures Functions as parameters Virtual methods Parameter passing Garbage collection 2 / 92
Outline 1. Run-time environments Intro Static layout Stack-based runtime environments Stack-based RTE with nested procedures Functions as parameters Virtual methods Parameter passing Garbage collection 3 / 92
Static & dynamic memory layout at runtime code area global/static area typical memory layout : for languages (as nowadays basically all) with stack • static memory • dynamic memory: free space • stack • heap heap Memory 4 / 92
Translated program code • code segment: almost always proc. 1 code for procedure 1 considered as statically allocated proc. 2 code for procedure 2 ⇒ neither moved nor changed at runtime • compiler aware of all addresses of . . . “chunks” of code: entry points of the procedures proc. n code for procedure n • but: • generated code often relocatable • final, absolute adresses given by Code memory linker / loader 5 / 92
Activation record space for arg’s (parameters) • schematic organization of activation records/activation block/stack frame space for bookkeeping info, including return . . . address • goal: realize • parameter passing space for local data • scoping rules /local variables treatment space for local temporaries • prepare for call/return behavior • calling conventions on a platform Schematic activation record 6 / 92
Outline 1. Run-time environments Intro Static layout Stack-based runtime environments Stack-based RTE with nested procedures Functions as parameters Virtual methods Parameter passing Garbage collection 7 / 92
Full static layout code for main proc. code for proc. 1 • static addresses of all of memory known to the compiler . . . • executable code • variables code for proc. n • all forms of auxiliary data (for instance big constants in the global data area program, e.g., string literals) • for instance: Fortran act. record of main proc. • nowadays rather seldom (or special activation record of proc. 1 applications like safety critical embedded systems) . . . activation record of proc. n 8 / 92
Fortran example PROGRAM TEST C O M M O N MAXSIZE INTEGER MAXSIZE REAL TABLE(10) ,TEMP MAXSIZE = 10 READ ∗ , TABLE(1 ) ,TABLE(2 ) ,TABLE(3) CALL QUADMEAN(TABLE, 3 ,TEMP) PRINT ∗ ,TEMP END SUBROUTINE QUADMEAN(A, SIZE ,QMEAN) N MAXSIZE C O M M O INTEGERMAXSIZE , SIZE REAL A( SIZE ) ,QMEAN, TEMP INTEGER K TEMP = 0.0 IF (( SIZE . GT . MAXSIZE ) . OR . ( SIZE . LT . 1 ) ) GOTO 99 DO 10 K = 1 , SIZE TEMP = TEMP + A(K)∗A(K) 10 CONTINUE 99 QMEAN = SQRT (TEMP/ SIZE ) RETURN END 9 / 92
Static memory layout example/runtime environment global area MAXSIZE TABLE (1) (2) in Fortan (here Fortran77) . . . main’s act. (10) • parameter passing as pointers to record the actual parameters TEMP • activation record for QUADMEAN 3 contains place for intermediate A results, compiler calculates, how much is needed. SIZE QMEAN • note: one possible memory layout for FORTRAN 77, details vary, return address Act. record of QUADMEAN other implementations exists as do TEMP more modern versions of Fortran K “scratch area” 10 / 92
Outline 1. Run-time environments Intro Static layout Stack-based runtime environments Stack-based RTE with nested procedures Functions as parameters Virtual methods Parameter passing Garbage collection 11 / 92
Stack-based runtime environments • so far: no recursion • everything static, including placement of activation records ⇒ also return addresses statically known • a very ancient and restrictive arrangement of the run-time envs • calls and returns (also without recursion) follow at runtime a LIFO (= stack-like) discipline stack of activation records • procedures as abstractions with own local data ⇒ run-time memory arrangement where procedure-local data together with other info (arrange proper returns, parameter passing) is organized as stack. • AKA: call stack , runtime stack • AR: exact format depends on language and platform 12 / 92
Situation in languages without local procedures • recursion, but all procedures are global • C-like languages Activation record info (besides local data, see later) • frame pointer • control link (or dynamic link ) a • (optional): stack pointer • return address a Later, we’ll encounter also static links (aka access links). 13 / 92
Euclid’s recursive gcd algo #include <s t d i o . h> i n t x , y ; gcd ( i n t u , v ) i n t i n t { i f ( v==0) return u ; gcd ( v , u % v ) ; e l s e return } i n t main () { s c a n f ( "%d%d",&x ,&y ) ; p r i n t f ( "%d\n" , gcd ( x , y ) ) ; return 0; } 14 / 92
Stack gcd x:15 global/static area y:10 “AR of main” • control link x:15 • aka: dynamic link y:10 a-record (1st. call) • refers to caller’s FP control link • frame pointer FP return address • points to a fixed location in x:10 the current a-record y:5 • stack pointer (SP) a-record (2nd. call) control link • border of current stack and return address unused memory x:5 • return address: program-address y:0 of call-site a-record (3rd. call) control link fp return address sp ↓ 15 / 92
Local and global variables and scoping i n t x = 2; /∗ g l o b a l var ∗/ g ( i n t ) ; /∗ prototype ∗/ void void f ( i n t n ) { s t a t i c i n t x = 1 ; g ( n ) ; x −− ; } • global variable x void g ( i n t m) • but: (different) x local to f { i n t y = m − 1; i f ( y > 0) • remember C: { f ( y ) ; • call by value x −− ; g ( y ) ; • static lexical scoping } } i n t main () { g ( x ) ; return 0 ; } 16 / 92
Activation records and activation trees • activation of a function: corresponds to the call of a function • activation record • data structure for run-time system • holds all relevant data for a function call and control-info in “standardized” form • control-behavior of functions: LIFO • if data cannot outlive activation of a function ⇒ activation records can be arranged in as stack (like here) • in this case: activation record AKA stack frame f and g example GCD main main() g(2) gcd(15,10) f(1) g(1) gcd(10,5) g(1) gcd(5,0) 17 / 92
Variable access and design of ARs • AR’s: structurally uniform per language (or at least compiler) / platform • different function defs, different size of AR ⇒ frames on the stack differently sized • note: FP points • not to the “top” of the frame/stack, but • to a well-chosen, well-defined position in the frame • other local data (local vars) accessible relative to that • fp : frame pointer • conventions • m (in this example): • higher addresses “higher up” parameter of g • stack “grows” towards lower addresses • in the picture: “pointers” to the “bottom” of the meant slot (e.g.: fp points to the control link) 18 / 92
Layout for arrays of statically known size void f ( i n t x , char c ) { i n t a [ 1 0 ] ; double y ; . . } name offset +5 x c +4 -24 a -32 y access of c and access for A[i] y ( − 24+2∗ i )( fp ) c : 4( fp ) y : − 32( fp ) 19 / 92
Back to the C code again (global and local variables) i n t x = 2; /∗ g l o b a l var ∗/ void g ( i n t ) ; /∗ prototype ∗/ void f ( i n t n ) { s t a t i c i n t x = 1 ; g ( n ) ; x −− ; } void g ( i n t m) { i n t y = m − 1; ( y > 0) i f { f ( y ) ; x −− ; g ( y ) ; } } i n t main () { g ( x ) ; return 0 ; } 20 / 92
2 snapshots of the call stack x:2 static x:1 (@f) x:1 static main x:0 (@f) m:2 main control link m:2 g return address control link g y:1 return address n:1 y:1 f control link m:1 return address control link g fp m:1 return address control link y:0 g fp sp return address ... y:0 sp ... • note: call by value, x in f static 21 / 92
How to do the “push and pop”: calling sequences • calling sequences: AKA as linking convention or calling conventions • for RT environments: uniform design not just of • data structures (=ARs), but also of • uniform actions being taken when calling/returning from a procedure • how to actually do the details of “push and pop” on the call-stack E.g: Parameter passing • not just where (in the ARs) to find value for the actual parameter needs to be defined, but well-defined steps (ultimately code) that copies it there (and potentially reads it from there) • “jointly” done by compiler + OS + HW • distribution of responsibilities between caller and callee: • who copies the parameter to the right place • who saves registers and restores them 22 / 92 • . . .
Recommend
More recommend
