Class 02: Compilation Steps

Held Monday, September 2, 2002

Summary

Today we consider the basics of compilation by looking at the precise steps that may be involved in translating some sample programs.

Assignments

• Write a few small Pascal programs that we can use for testing.
• Fill out the introductory survey.
• Scan chapter 2 of ASU.
• Read chapter 3 of ASU.

Notes

• I've updated the syllabus and course at a glance.
  • I still need to add due dates and exams.
• You don't need to do anything to prepare for lab tomorrow.
• I'm still working on the Electronic Course Assistant.
  • Yes, you need to accept the certificate.
  • Please change your password.
• Don't forget to fill out the introductory survey.

Overview

• The steps of compilation
• Sample programs
• Lexical analysis
• Syntactic analysis
• Generating intermediate representation trees
• Semantic analysis
• Generating assembly code
• Optimization

Compilation Phases

• As I may have mentioned earlier, a compiler does its translation in phases, one phase at a time.
• There are a variety of ways to express these phases and different compilers may choose different ways to break up the compilation process.
• The simplest is the two-phase compiler. The first phase (called the front end) translates from the original high-level language to a simple common intermediate language. The second phase (called the back end) translates the intermediate language to assembler or machine code.
• The front end is language dependent. The back end is machine dependent.
• The computer science education community has some debate about what the undergraduate compilers course should study.
• Why to emphasize the back end:
  • Almost all current research involves the back end (e.g., optimizations).
  • Much of the front end can be automated using long-standing tools.
• Why to emphasize the front end:
  • Helps ground theory.
  • Most programmers will implement small languages and won't want to spend effort on the back end.

A Sample Program

• Our goal for today is to follow the steps of compilation for some sample programs (or portions of programs).
• I'll rely on your sample programs for most of the work, but we'll start with one of mine.

  { Program: count
    Purpose: Prints the numbers from 1 to max
    Author:  Samuel A. Rebelsky
    Version: 1.0 of 26 January 2001
  }
  program count(output);
  
  const max = 20;
  
  { Procedure:  countto
    Parameters: top, an integer
    Purpose:    Prints the numbers from 1 to top as reals
    Produces:   Nothing
    Pre:        top >= 1
    Post:       Values have been sidplayed
  }
  procedure countto(top: integer);
    var i: integer; { counter variable }
  begin
    for i := 1 to top do
      writeln(i + 0.0)
  end;
  
  begin
    countto(max)
  end.
  

Lexical Analysis

• The goal of lexical analysis is to group characters together (or pull them apart) to build a sequence of simple tokens and to eliminate unneccessary parts, such as comments and sapces.

  PROGRAM ID(count) OPEN_PAREN ID(output) CLOSE_PAREN SEMICOLON CONST
  ID(max) EQUALS NUMBER(20) SEMICOLON PROCEDURE ID(countto) OPEN_PAREN
  ID(top) COLON TYPE(integer) CLOSE_PAREN VAR ID(i) COLON TYPE(integer)
  SEMICOLON BEGIN FOR ID(i) ASSIGN NUMBER(1) TO ID(max) DO ID(writeln)
  OPEN_PAREN ID(i) OPERATOR(+) NUMBER(0.0) CLOSE_PAREN END SEMICOLON BEGIN
  ID(countto) OPEN_PAREN ID(max) CLOSE_PAREN END PERIOD
  

Syntactic Analysis

• The goal of syntactic analysis is to group the tokens together to make structures (which turn out to be tree-like).

  program
    program-head
      PROGRAM 
      ID(count) 
      OPEN_PAREN 
      file-identifier
        ID(output) 
      CLOSE_PAREN 
      SEMICOLON 
    block
      label-declaration
        empty
      constant-definition-part
        CONST
        constant-definition
          ID(max) 
          EQUALS 
          constant
            NUMBER(20) 
        more-constant-defintions
          empty
      type-definition-part
        empty
      variable-definition-part
        empty
      procedure-definition-part
  ...
  

Intermediate Representation Trees

• We often throw away the useless tokens (and perhaps add some extra information) once we've built the first tree. Some people refer to these variant trees as intermediate representation trees.
• It may also help to think of these as objects with particular attributes

  program
    name: ID(count)
    procedures: ...
    body: ...
  

Semantic Analysis

• Once the tree is built, we can do a form of tree walk to verify certain aspects of the program that are difficult to describe or represent syntactically:
  • Variable lifetimes
  • Types
  • Etc.
• You can also build symbol tables and such.
• You may also look at register usage at this point.

Translation

• At this point, you may translate to something approximating the assembly code. (We'll have some fun here.)

Some Potential Bugs

• What happens if i is a real number?
• What happens if we try to change max?
• What happens if we try to print i after the loop?