• No results found

RUN­TIME ENVIRONMENT: SOURCE LANGUAGE ISSUES Run­Time Environment

In document Cs6660 Compiler Design Appasami (Page 113-119)

UNIT III  SYNTAX ANALYSIS 3.1 NEED AND ROLE OF THE PARSER

5. The initial state of the parser is the one constructed from the set of items containing [S'

4.9  RUN­TIME ENVIRONMENT: SOURCE LANGUAGE ISSUES Run­Time Environment

 Run Time Environment establishes relationships between names and data objects. 

 The allocation and de­allocation of data objects are managed by the Run Time Environment 

 Each execution of a procedure is referred to as an activation of the procedure. 

 If the procedure is recursive, several of its activations may & alive at the same time. Each call of a procedure leads to an activation that may manipulate data objects allocated for its use. 

 The representation of a data object at run time is determined by its type. 

 Often, elementary data types, such as characters, integers, and reals can be represented by equivalent data objects in the target machine. 

 However, aggregates, such as arrays, strings, and structures, are usually represented by collections of primitive objects. 

Source Language Issues 1. Procedure  2. Activation Trees  3. Control Stack 

4. The Scope of a Declaration  5. Bindings of Names 

Procedure

 A procedure definition is a declaration that associates an identifier with a statement. The identifier is the procedure name and the statement is the procedure body. 

 A procedure returns value for the called function. 

 A complete program will also be treated as a procedure. 

 When a procedure name appears within an executable statement, we say that the procedure is called at that point. 

 The basic idea is that a procedure call executes the procedure body. 

 Some of the identifiers appearing in a procedure definition are special, and are called formal parameters of the procedure. 

 Actual parameters may be passed to a called procedure. 

 Procedures can contains local and global variables. 

Activation Trees

 We make the following assumptions about the flow of control among procedures during the execution of a program: 

1. Control flows sequentially; that is, the execution of a program consists of a sequence of steps, with control king at some specific point in the program at each step. 

2. Each execution of a procedure starts at the beginning of the procedure body and eventually returns control to the point immediately following the place where the procedure was called. This means the flow of control between procedures can be depicted using trees. 

Each execution of a procedure body Is referred to as an  activation  of the procedure, The lifetime of an activation of a procedure p is the sequence of steps between the first and last steps in the execution of the procedure body. 

If  a  and  b  arc procedure activations, then their lifetimes are either non­overlapping or

nested. 

CS6660 Compiler Design Unit IV 4.17

 A procedure is recursive if a new activation can begin before an earlier activation of the same procedure has ended. 

 The lifetime of the activation quicksort (1, 9) is the sequence of steps executed between printing enter quicksort (1, 9) and printing leave quicksort(l, 9). 

The following are the rules to construct an activation tree:

1. Each node represents an activation of a procedure. 

2. The root node represents the activation of the main program. 

3. The node for a is the parent of the node for b if and only if control flows from activation a to b. 

4. The node for a is to the left of the node for b if and only if the lifetime of a occurs before the lifetime of b. 

along the path from n to the root.

CS6660 Compiler Design Unit IV 4.18

Example 4.10:  Figure 4.8 shows nodes from the activation tree of Figure 4.9 that have been reached when control enters the activation represented by q(2,3 ) . Activations with labels r, p(1, 9), p(1, 3), and q(1, 3) have executed to completion, so the figure contains dashed lines to their nodes.

The solid lines mark the path from q(2, 3) to the root.

Figure 4.9: The control stack contains nodes along a path to the root.

The Scope of a Declaration

 A declaration in a language is a syntactic construct that associates information with a name.

Declarations may be explicit, as in the  Pascal  fragment  var i : integer;  or they may be Implicit. For example, any variable name starting with I is assumed to denote an integer in a Fortran program, unless otherwise declared. 

 The scope rules of a language determine which declaration of a name applies when the name appears in the text of a program. 

 The  portion  of the  program  to  which  a  declaration  applies is  called  the  scope  of that declaration. An occurrence of a name in a procedure is said to be local to the procedure if it is in the scope of a declaration within the procedure; otherwise, the occurrence is said to be nonlocal. 

 At compile time, the symbol table can be used to find the declaration that applies to an occurrence of a name. 

 Special, static, global, volatile, final and so on are also used to declare variables. 

Bindings of Names

environment state

name

storag

e value

Figure 4.10: Two­stage mapping from names to values

Environments   and   states   are   different;   an   assignment   changes   the   state,   but   not   the environment. For example, suppose that storage address 100, associated with variable pi, holds 0.

After the assignment pi := 3. 14, the same storage address is associated with pi, but the value held there is 3.14.

CS6660 Compiler Design Unit IV 4.19

When an environment associates storage location s with a name x, we say that x is bound to s; the association itself is referred to as a binding of x. The term storage "location" is to be taken figuratively. If x is not of a basic type, the storage s for x may be a collection of memory words.

Static notion Dynamic counterpart

definition of a procedure activations of the procedure

Declaration of a name bindings of the name

Scope of a declaration lifetime of a binding

In document Cs6660 Compiler Design Appasami (Page 113-119)

Related documents