Run-time Environments - Compiler Construction - Lecture Slides, Slides of Compiler Construction

Download Run-time Environments - Compiler Construction - Lecture Slides and more Slides Compiler Construction in PDF only on Docsity!

Run-time Environments

Status

• We have covered the front-end phases
  • Lexical analysis
  • Parsing
  • Semantic analysis
• Next are the back-end phases
  • Optimization
  • Code generation
• We’ll do code generation first...

Outline

• Management of run-time resources
• Correspondence between static (compile-time) and dynamic (run-time) structures
• Storage organization

Run-time Resources

• Execution of a program is initially under the control of the operating system
• When a program is invoked:
  • The OS allocates space for the program
  • The code is loaded into part of the space
  • The OS jumps to the entry point (i.e., “main”)

Notes

• Our pictures of machine organization have:
  • Low address at the top
  • High address at the bottom
  • Lines delimiting areas for different kinds of data
• These pictures are simplifications
  • E.g., not all memory need be contiguous
• In some textbooks lower addresses are at bottom

What is Other Space?

• Holds all data for the program
• Other Space = Data Space
• Compiler is responsible for:
  • Generating code
  • Orchestrating use of the data area

Assumptions about Execution

1. Execution is sequential; control moves from one point in a program to another in a well- defined order
2. When a procedure is called, control eventually returns to the point immediately after the call

Do these assumptions always hold?

Activations

• An invocation of procedure P is an activation of P
• The lifetime of an activation of P is
  • All the steps to execute P
  • Including all the steps in procedures that P calls

Activation Trees

• Assumption (2) requires that when P calls Q, then Q returns before P does
• Lifetimes of procedure activations are properly nested
• Activation lifetimes can be depicted as a tree

Example

Class Main {

g() : Int { 1 }; f(): Int { g() }; main(): Int {{ g(); f(); }};

} Main

g f

g

Example

Class Main {

g() : Int { 1 }; f(): Int { g() }; main(): Int {{ g(); f(); }};

} Main Stack Main

Example

Class Main {

g() : Int { 1 }; f(): Int { g() }; main(): Int {{ g(); f(); }};

} Main

g

Stack Main g

Example

Class Main {

g() : Int { 1 }; f(): Int { g() }; main(): Int {{ g(); f(); }};

} Main

g f

g

Stack Main f g

Notes

• The activation tree depends on run-time behavior
• The activation tree may be different for every program input
• Since activations are properly nested, a stack can track currently active procedures