Intermediate Representations

Intermediate Representations

Now that we have an understanding of the basic phases of a compiler, we will discuss the types of data that flows between these phases. I will not attempt to describe every scheme for representing the intermediate results of the compilation process. I just want to show you one way to give you a concrete picture of what goes on. The organization I will outline corresponds closely to what will be used in the course project.

1. Source Code.

   • The scanner begins with the representation of the program with which we are all most familiar: A simple sequence of characters.

   • This representation is difficult to work with. If you have ever written a program that had to accept fairly free-format input you know the joys of skipping blanks and watching out for new-lines (not to mention tabs).

2. Tokens

   • A token is an independently meaningful subsequence of characters in a program. Identifiers, keywords, string constants and operators are all tokens.

   • The scanner converts the program from a sequence of characters into a sequence of tokens.

   • In the scanner's output, each token is typically represented by a pair of values. The first value indicates the token class (identifier, integer constant, etc.). The second value -- the token identifier or token number -- distinguishes tokens within the same class.

   • The use of a pair of values to represent tokens follows from the different interests of the phases that consume the scanner's output:

     • The parser doesn't need to know what identifier or constant it is looking at to determine the syntactic structure of some input. It just needs to know that it is looking at an identifier rather than a constant, a plus sign, or some keyword.

       The first element of a pair used to represent a token provides all the information the parser needs.

     • The semantic processor definitely needs to know what identifier or constant was used.

       The second element of a token pair encodes this information. The parser typically just passes this on to the later phases without examining it.

   • Thus, the scanner transforms the program from a sequence of characters to a sequence of pairs.

3. The Symbol Table

   • The scanner needs some set of values it can use as token identifier for program variables and method/function names.

   • The purpose of these token identifiers is to somehow let later phases of the compiler efficiently determine which source program name occurred in a given context.

   • Actually, what the later phases will really typically need to know is the attributes associated with the name that appeared in a given context (its type and memory location) rather than its actual identity.

   • This can be accomplished by keeping the attributes for each symbolic name in an object/structure and using a pointer/reference to this object as the token number.

   • This collection of objects is called the symbol table

4. Syntax Trees

   • There are many possible internal forms that can be produced by the syntax analyzer. We will use what are called syntax trees.

   • BEWARE: Syntax trees are similar to but different from parse trees. To emphasize the difference they are sometimes called abstract syntax trees.

   • The basic idea behind a syntax tree is a generalization of expressions trees. Consider the expression tree for the expression a*(b+c) shown in figure *.

     

     Expression Tree
      

     • Each subtree represents a phrase.

     • The root of the subtree is labeled with the "type" of the phrase.

     • The subtrees attached to an internal node represent sub-components of a phrase.

   • In a general syntax tree, one simply recognizes that the root labels are really phrase types, not operators. For example, the syntax tree for:

     if ( x <= 0 ) { flag = ; }

     would look something like the tree in figure *.

     

     Syntax Tree for If Statement
      

   • Note that:

     • In the character form of a program, keywords and punctation characters determine the phrase structure of a program. In the tree form, the internal nodes identify phrase types.

     • As a result, the only tokens that appear in such a tree are identifiers, constants and the like. Keywords and operators determine the form of the tree but they don't appear in it.

     • The tokens that do appear form the leaves.

   • As a result, pointers from internal nodes of a syntax tree to its leaves are typically actually pointers to objects in the symbol table. (Note: This means the tree really isn't a tree).

5. Semantic Information

   • In your compilers, semantic processing will not produce a new representation of the program. It will simply "complete" the existing one.

     • For example, during semantic processing attributes of identifiers are extracted from declarations and stored in symbol table entries.

   • In the descriptions of other compilers found in the readings, you will find discussion of other intermediate forms including three address code, quadruples, etc.

     • In my view, these intermediate forms are more appropriately described when considering the sub-phases of code synthesis.

Intermediate Representations