Compiler 2011-8-re1

  • 388 views
Uploaded on

storage allocation stratagies and storage organization

storage allocation stratagies and storage organization

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
388
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1Compiler ConstructionCompiler ConstructionRuntime EnvironmentRuntime Environment
  • 2. 2Run-Time Environments (Chapter 7)
  • 3. 3Run-Time Environments (Chapter 7)A lot has to happen at run time to get your programrunning.At run time, we need a system to map NAMES (in thesource program) to STORAGE on the machine.Allocation and deallocation of memory is handled by aRUN-TIME SUPPORT SYSTEM typically linked andloaded along with the compiled target code.One of the primary responsibilities of the run-time system isto manage ACTIVATIONS of procedures.
  • 4. 4ProceduresWe assume in this lecture that a program is no more than acollection of PROCEDURES.A PROCEDURE DEFINTION associates an identifier with astatement (a statement could actually be a block ofstatements, of course).The identifier is called the PROCEDURE NAME.The statement is called the PROCEDURE BODY.A PROCEDURE CALL is an invocation of a procedurewithin an executable statement.Procedures that return values are normally calledFUNCTIONS, but we’ll just use the name “procedure.”
  • 5. 5Example programprogram sort( input, output );var a: array [ 0..10 ] of integer;procedure readarray;var i: integer;beginfor i := 1 to 9 do read( a[i] )end;function partition( y, z: integer ) : integer;var i, j, x, v: integer;begin …end;procedure quicksort( m, n: integer );var i: integer;beginif ( n > m ) thenbegini :=partition(m,n );quicksort(m,i-1);quicksor
  • 6. 6Parameters of proceduresThe FORMAL PARAMETERS are special identifiersdeclared in the procedure definition.The formal parameters must correspond to the ACTUALPARAMETERS in the function call.E.g. m and n are formal parameters of the quicksortprocedure. The actual parameters in the call to quicksortin the main program are 1 and 9.Actual parameters can be a simple identifier, or morecomplex expressions.
  • 7. 7Control flowLet’s assume, as in most mainstream programminglanguages, that we have SEQUENTIAL program flow.Procedure execution begins at the first statement of theprocedure body.When a procedure returns, execution returns to theinstruction immediately following the procedure call.
  • 8. 8ActivationsEvery execution of a procedure is called an ACTIVATION.The LIFETIME of an activation of procedure P is thesequence of steps between the first and last steps of P’sbody, including any procedures called while P is running.Normally, when control flows from one activation to another,it must (eventually) return to the same activation.When activations are thusly nested, we can representcontrol flow with ACTIVATION TREES.
  • 9. 9Activation treesExecution begins…enter readarrayleave readarrayenter quicksort(1,9)enter partition(1,9)leave partition(1,9)enter quicksort(1,3)…leave quicksort(1,3)enter quicksort(5,9)…leave quicksort(5,9)leave quicksort(1,9)Execution terminated.
  • 10. 10Control stacksWe can use a stack to keep track of currently-activeactivations.We push a record onto the stack when a procedure iscalled, and pop that record off the stack when theprocedure returns.At any point in time, the control stack represents a pathfrom the root of the activation tree to one of the nodes.
  • 11. 11Example control stackThis partial activation treecorresponds to control stack(growing downward)sq(1,9)q(1,3)q(2,3)
  • 12. 12DeclarationsEvery DECLARATION associates some information with aname.In Pascal and C, declarations are EXPLICIT:var i : integer;assocates the TYPE integer with the NAME i.Some languages like Perl and Python have IMPLICITdeclarations.
  • 13. 13Scope of a declarationThe SCOPING RULES of a language determine where in aprogram a declaration applies.The SCOPE of a declaration is the portion of the programwhere the declaration applies.An occurrence of a name in a procedure P is LOCAL to P ifit is in the scope of a declaration made in P.If the relevant declaration is not in P, we say the referenceis NON-LOCAL.During compilation, we use the symbol table to find theright declaration for a given occurrence of a name.The symbol table should return the entry if the name is inscope, or otherwise return nothing.
  • 14. 14Environments and statesThe ENVIRONMENT is a function mapping from names tostorage locations.The STATE is a function mapping storage locations to thevalues held in those locations.Environments map names to l-values.States map l-values to r-values.
  • 15. 15Name bindingWhen an environment maps name x to storage location s,we say “x is BOUND to s”. The association is a BINDING.Assignments change the state, but NOT the environment:pi := 3.14changes the value held in the storage location for pi, butdoes NOT change the location (the binding) of pi.Bindings do change, however, during execution, as we movefrom activation to activation.
  • 16. 16Run-time system designThe run-time system keeps track of a program’s dynamic components.There are many relevant criteria for its design:1. Can procedures be recursive?2. What happens to values of local names when control returns fromthe activations of a procedure?3. Can a procedure refer to nonlocal names?4. How are parameters passed when procedures are called?5. Can procedures be passed as parameters?6. Can procedures be returned from procedures?7. Can programs dynamically allocate their own storage?8. Does storage get deallocated explicitly or implicitly?Static notion Dynamic counterpartdefinition of a procedure activations of the proceduredeclarations of a name bindings of the namescope of a declaration lifetime of a binding
  • 17. 17Storage allocation
  • 18. 18Organization of storageFixed-size objects can beplaced in predefinedlocations.The heap and the stackneed room to grow,however.
  • 19. 19Run-time stack and heapThe STACK is used to store:− Procedure activations.− The status of the machine just before calling a procedure, sothat the status can be restored when the called procedurereturns.The HEAP stores data allocated under program control(e.g. by malloc() in C).
  • 20. 20Activation recordsAny information needed for a singleactivation of a procedure is storedin the ACTIVATION RECORD(sometimes called the STACKFRAME).Today, we’ll assume the stack growsDOWNWARD, as on, e.g., theIntel architecture.The activation record gets pushed foreach procedure call and poppedfor each procedure return. (the access link is the “dynamiclink” in Sebesta’s terminology)
  • 21. 21Compile-time layout of localsUsually the BYTE is the smallest addressable unit of storage.We lay out locals in the order they are declared.Each local has an OFFSET from the beginning of the activation record(or local data area of the record).Some data objects require alignment with machine words.Any resulting wasted space is called PADDING.Type Size (typical) Alignment (typical)char 8 8short 16 16int 32 32float 32 32double 64 32
  • 22. 22Storage allocation strategies
  • 23. 23Static allocationStatically allocated names are bound to storage at compiletime.Storage bindings of statically allocated names neverchange, so even if a name is local to a procedure, itsname is always bound to the same storage.The compiler uses the type of a name (retrieved from thesymbol table) to determine storage size required.The required number of bytes (possibly aligned) is setaside for the name.The address of the storage is fixed at compile time.
  • 24. 24Static allocationLimitations:− The size required must be known at compile time.− Recursive procedures cannot be implemented as all locals arestatically allocated.− No data structure can be created dynamicaly as all data is static.
  • 25. 25Stack-dynamic allocationStorage is organized as a stack.Activation records are pushed and popped.Locals and parameters are contained in the activationrecords for the call.This means locals are bound to fresh storage on every call.If we have a stack growing downwards, we just need astack_top pointer.To allocate a new activation record, we just increasestack_top.To deallocate an existing activation record, we justdecrease stack_top.
  • 26. 26Position inActivation TreeActivation Recordson the Stack
  • 27. 27Address generation in stack allocationThe position of the activation record on the stack cannot bedetermined statically.Therefore the compiler must generate addressesRELATIVE to the activation record.If we have a downward-growing stack and a stack_toppointer, we generate addresses of the form stack_top +offset
  • 28. 28Calling sequencesThe CALLING SEQUENCE for a procedure allocates anactivation record and fills its fields in with appropriatevalues.The RETURN SEQUENCE restores the machine state toallow execution of the calling procedure to continue.Some of the calling sequence code is part of the callingprocedure, and some is part of the called procedure.What goes where depends on the language and machinearchitecture.
  • 29. 29
  • 30. 30Sample calling sequence1. Caller evaluates the actual parameters and places theminto the activation record of the callee.2. Caller stores a return address and old value forstack_top in the callee’s activation record.3. Caller increments stack_top to the beginning of thetemporaries and locals for the callee.4. Caller branches to the code for the callee.5. Callee saves all needed register values and status.6. Callee initializes its locals and begins execution.
  • 31. 31Sample return sequence1. Callee places the return value at the correct location inthe activation record (next to caller’s activation record)2. Callee uses status information previously saved torestore stack_top and the other registers.3. Callee branches to the return address previouslyrequested by the caller.4. [Optional] Caller copies the return value into its ownactivation record and uses it to evaluate an expression.
  • 32. 32Variable-length dataIn some languages, array size can depend on a valuepassed to the procedure as a parameter.This and any other variable-sized data can still be allocatedon the stack, but BELOW the callee’s activation record.In the activation record itself, we simply store POINTERS tothe to-be-allocated data.
  • 33. 33Example of variable- length dataAll variable-lengthdata is pointed tofrom the localdata area.
  • 34. 34Dangling pointersStack dynamic allocation means that pointers might end upDANGLING. Every novice C programmer makes thismistake at least once:int main( void ) { int *dangle( void ) {int *p; int i = 23;p = dangle(); return &i;} }
  • 35. 35Heap allocationSome languages do not have tree-structured allocations.In these cases, activations have to be allocated on theheap.This allows strange situations, like callee activations thatlive longer than their callers’ activations.This is not common.