Computer Science: Compiler Design and Programming Languages, Study notes of Health sciences

An overview of various topics in compiler design and programming languages, including pascal, lexical analysis, syntax analysis, code generation, optimization, and register management. It covers concepts such as regular grammars, hand-written lexical analyzers, context-free grammars, operator precedence, recursive descent parsing, shift-reduce parsing, intermediate code, symbol tables, code generation from trees, register assignment, array references, subroutine calls, optimization techniques like constant folding and partial evaluation, and types as tree structures.

Typology: Study notes

Pre 2010

Uploaded on 08/30/2009

koofers-user-p3g
koofers-user-p3g 🇺🇸

5

(1)

10 documents

1 / 371

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS 375, Compilers: Class Notes
Gordon S. Novak Jr.
Department of Computer Sciences
University of Texas at Austin
http://www.cs.utexas.edu/users/novak
Copyright c
°Gordon S. Novak Jr.1
1A few slides reproduce figures from Aho, Lam, Sethi, and Ullman, Compilers: Principles, Techniques,
and Tools, Addison-Wesley; these have footnote credits.
1
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Partial preview of the text

Download Computer Science: Compiler Design and Programming Languages and more Study notes Health sciences in PDF only on Docsity!

CS 375, Compilers: Class Notes

Gordon S. Novak Jr. Department of Computer Sciences University of Texas at Austin [email protected] http://www.cs.utexas.edu/users/novak

Copyright c© Gordon S. Novak Jr.^1

(^1) A few slides reproduce figures from Aho, Lam, Sethi, and Ullman, Compilers: Principles, Techniques, and Tools, Addison-Wesley; these have footnote credits.

I wish to preach not the doctrine of ignoble ease, but the doctrine of the strenuous life.

  • Theodore Roosevelt

Innovation requires Austin, Texas. We need faster chips and great compilers. Both those things are from Austin.

  • Guy Kawasaki

Pascal Test Program

{ program 4.9 from Jensen & Wirth: graph1.pas }

program graph1(output); const d = 0.0625; {1/16, 16 lines for [x,x+1]} s = 32; {32 character widths for [y,y+1]} h = 34; {character position of x-axis} c = 6.28318; {2pi} lim = 32; var x,y : real; i,n : integer; begin for i := 0 to lim do begin x := di; y := exp(-x)sin(cx); n := round(sy) + h; repeat write(’ ’); n := n- until n=0; writeln(’’) end end.

calling graph


Introduction

  • What a compiler does; why we need compilers
  • Parts of a compiler and what they do
  • Data flow between the parts

Assembly Language

Assembly Language is much easier to program in than Machine Language:

  • Addresses are filled in by assembler: easy to insert code.
  • Mnemonic codes for operations, e.g. LDA.
  • Bit fields are handled by assembler.

However, it still is fairly difficult to use:

  • One-to-one translation: one output instruction per source line. - Programmers write a fixed (small: 8 to 16) number of lines of code per day, independent of language. - A programmer costs $1 per minute!
  • Minimal error checking.

High-Level Language

  • Higher-level language constructs:
    • Arithmetic Expressions: x := a + b * c
    • Control Constructs: while expression do statement
    • Data Structures: people[i].spouse^.mother
    • Messages: obj.draw()
  • One-to-many translation: one statement of input generates many machine instructions.
  • Error checking, e.g. detection of type errors.

Sequential Phases of a Compiler^3

Input is a source program.

  • Lexical analyzer
  • Syntax analyzer
    • Semantic analyzer
    • Intermediate code generator
  • Code optimizer
  • Code generator

We may think of this as an analysis process followed by synthesis of the output.

These two modules are active throughout the compilation process:

  • Symbol table manager
  • Error handler

(^3) This slide adapted from one by John Werth.

Data Flow through the Compiler

Source Program I/O V IF I>J THEN K := 0 Line Handler Chars V IF I>J THEN K := 0 Lexical Analyzer | Tokens | Res Id Op Id Res Id Op Num | IF I > J THEN K := 0 V Syntax Analyzer | | IF | /
Trees | > := | / \ /
| I J K 0 V Code Generator | LDA I | CMP J Code | BLE L | LDAI 0 | STA K V L17:

Lexical Analyzer

The Lexical Analyzer (or Lexer) will convert characters into “words” or tokens, such as:

  • Identifiers, e.g. position
  • Reserved words or keywords, e.g. begin
  • Numbers, e.g. 3.1415926e
  • Operators, e.g. >=

The Lexical Analyzer may be called as a subroutine such as gettoken() to get the next token from the input string. It, in turn, calls the Line Handler routines.

The Lexical Analyzer returns a token data structure, consisting of:

  • Token Type: identifier, reserved word, number, operator.
  • Token Value:
    • Identifiers: string and symbol table pointer
    • Reserved words: integer code.
    • Numbers: internal binary form.
    • Operators: integer code.

Syntactic Analyzer

The Syntactic Analyzer (or Parser) will analyze groups of related tokens (“words”) that form larger constructs (“sentences”) such as arithmetic expressions and statements:

  • while expression do statement ;
  • x := a + b * 7

It will convert the linear string of tokens into structured representations such as expression trees and program flow graphs.

Lexical Analysis

If speed is needed, the Line Handler and Lexical Analyzer can be coded in assembly language.

The Lexical Analyzer does the following:

  • Reads input characters.
  • Groups characters into meaningful units or “words”, producing data structures called tokens.
  • Converts units to internal form, e.g. converts numbers to machine binary form.
  • Serves as a front end for and provides input to the Parser.

Character Classes

At the lowest level of grammar, there is a need to classify characters into classes. This can be done by lookup in an array indexed by the character code. Typical classes include:

  • Numerals: 0 1 2 3 4 5 6 7 8 9
  • Alphabetic: A B C ... Z
  • Whitespace: blank, tab, newline.
  • Special: ( ) [ ] + =. etc.
  • Other: characters not in the language.

Special characters may be mapped to consecutive integers to allow the resulting index to be used in case statements.

Char ASCII Class ... 0 608 0 1 618 0 ... A 1018 1 B 1028 1 ...

Hand-written Lexical Analyzer

A lexical analyzer can easily be written by hand. Typically, such a program will call functions getchar() and peekchar() to get characters from the input.

The lexical analyzer is likewise called as a function, with an entry such as gettoken(). The program is structured as:

  1. A “big switch” that skips white space, peeks at the next character to guess what kind of token will be next, and calls the appropriate routine.
  2. A set of routines to get particular kinds of tokens, such as identifiers, numbers, strings, or operators.

Typically, a routine will process all tokens that look alike, e.g., all kinds of numbers, or both identifiers and reserved words.

Example Lexical Analyzer

/* The ‘‘big switch’’: guess token type, call a routine to parse it / TOKEN gettoken() { TOKEN tok; int c, cclass; tok = talloc(); / allocate a token / skipblanks(); / and comments */ if ((c = peekchar()) != EOF) { cclass = CHARCLASS[c]; if (cclass == ALPHA) identifier(tok); else if (cclass == NUMERIC) number(tok); else if (c == ’\’’) getstring(tok); else special(tok); } else EOFFLG = 1; return(tok); }