Generating 3-Address Code from an Attribute Grammar

Similar documents
Principle of Compilers Lecture VIII: Intermediate Code Generation. Alessandro Artale

Dixita Kagathara Page 1

Formal Languages and Compilers Lecture X Intermediate Code Generation

Intermediate Code Generation Part II

Time : 1 Hour Max Marks : 30

CS2210: Compiler Construction. Code Generation

Intermediate Code Generation

ΕΠΛ323 - Θεωρία και Πρακτική Μεταγλωττιστών

Syntax-Directed Translation

UNIT-3. (if we were doing an infix to postfix translator) Figure: conceptual view of syntax directed translation.

Module 26 Backpatching and Procedures

CSc 453 Intermediate Code Generation

Concepts Introduced in Chapter 6

COP5621 Exam 3 - Spring 2005

NARESHKUMAR.R, AP\CSE, MAHALAKSHMI ENGINEERING COLLEGE, TRICHY Page 1

CSCI565 Compiler Design

Formal Languages and Compilers Lecture IX Semantic Analysis: Type Chec. Type Checking & Symbol Table

Object Code (Machine Code) Dr. D. M. Akbar Hussain Department of Software Engineering & Media Technology. Three Address Code

Module 27 Switch-case statements and Run-time storage management

Lexical Considerations

Intermediate Representations

UNIT IV INTERMEDIATE CODE GENERATION

CSCI565 Compiler Design

Writing Evaluators MIF08. Laure Gonnord

Concepts Introduced in Chapter 6

Lexical Considerations

Compilers. Compiler Construction Tutorial The Front-end

Operational Semantics of Cool

MORE SCHEME. 1 What Would Scheme Print? COMPUTER SCIENCE MENTORS 61A. October 30 to November 3, Solution: Solutions begin on the following page.

PART 6 - RUN-TIME ENVIRONMENT. F. Wotawa TU Graz) Compiler Construction Summer term / 309

1 Lexical Considerations

CMPSC 160 Translation of Programming Languages. Three-Address Code

Intermediate Code Generation

Begin at the beginning

CS61A Midterm 2 Review (v1.1)

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far

C++11: 10 Features You Should be Using. Gordon R&D Runtime Engineer Codeplay Software Ltd.

OCaml. ML Flow. Complex types: Lists. Complex types: Lists. The PL for the discerning hacker. All elements must have same type.

Intermediate Code Generation

Common Misunderstandings from Exam 1 Material

Type checking of statements We change the start rule from P D ; E to P D ; S and add the following rules for statements: S id := E

Every language has its own scoping rules. For example, what is the scope of variable j in this Java program?

KU Compilerbau - Programming Assignment

CS 164 Handout 16. Final Examination. There are nine questions on the exam, some in multiple parts. You have 3 hours to work on the

Intermediate Code Generation

Intermediate Code Generation

CS164: Programming Assignment 5 Decaf Semantic Analysis and Code Generation

Tail Recursion: Factorial. Begin at the beginning. How does it execute? Tail recursion. Tail recursive factorial. Tail recursive factorial

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

Semantic analysis and intermediate representations. Which methods / formalisms are used in the various phases during the analysis?

Homework #3: CMPT-379 Distributed on Oct 23; due on Nov 6 Anoop Sarkar

Lecture 7: Type Systems and Symbol Tables. CS 540 George Mason University

CSC 467 Lecture 13-14: Semantic Analysis

Type Checking. Error Checking

News. Programming Languages. Complex types: Lists. Recap: ML s Holy Trinity. CSE 130: Spring 2012

Programming Languages

DaMPL. Language Reference Manual. Henrique Grando

Java Basic Programming Constructs

Logical Methods in... using Haskell Getting Started

CS 6353 Compiler Construction Project Assignments

CS1622. Semantic Analysis. The Compiler So Far. Lecture 15 Semantic Analysis. How to build symbol tables How to use them to find

Operational Semantics. One-Slide Summary. Lecture Outline

Static Program Analysis Part 1 the TIP language

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Notation. The rules. Evaluation Rules So Far.

Crash Course in Java. Why Java? Java notes for C++ programmers. Network Programming in Java is very different than in C/C++

Type Checking. Chapter 6, Section 6.3, 6.5

CSE 340 Fall 2014 Project 4

Dynamic Types, Concurrency, Type and effect system Section and Practice Problems Apr 24 27, 2018

Flow Control. CSC215 Lecture

Boolean expressions. Elements of Programming Languages. Conditionals. What use is this?

CSE443 Compilers. Dr. Carl Alphonce 343 Davis Hall

Programming Language Concepts, cs2104 Lecture 04 ( )

Specifying Syntax. An English Grammar. Components of a Grammar. Language Specification. Types of Grammars. 1. Terminal symbols or terminals, Σ

Topic 1: Introduction

Functional Programming. Pure Functional Programming

Problem Score Max Score 1 Syntax directed translation & type

Decaf Language Reference

Final CSE 131B Spring 2004

Below are example solutions for each of the questions. These are not the only possible answers, but they are the most common ones.

CS 139 Practice Midterm Questions #2

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

CSC324- TUTORIAL 5. Shems Saleh* *Some slides inspired by/based on Afsaneh Fazly s slides

Intermediate Code Generation

Semantic Analysis and Type Checking

COMP-520 GoLite Tutorial

CS 320: Concepts of Programming Languages

Chapter 6 Intermediate Code Generation

Final exam. Final exam will be 12 problems, drop any 2. Cumulative up to and including week 14 (emphasis on weeks 9-14: classes & pointers)

Plan (next 4 weeks) 1. Fast forward. 2. Rewind. 3. Slow motion. Rapid introduction to what s in OCaml. Go over the pieces individually

Summer 2017 Discussion 10: July 25, Introduction. 2 Primitives and Define

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

QUark Language Reference Manual

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

Building lexical and syntactic analyzers. Chapter 3. Syntactic sugar causes cancer of the semicolon. A. Perlis. Chomsky Hierarchy

The Compiler So Far. Lexical analysis Detects inputs with illegal tokens. Overview of Semantic Analysis

COMP 202 Java in one week

Chapter 1 Getting Started

BOOLEAN EXPRESSIONS CONTROL FLOW (IF-ELSE) INPUT/OUTPUT. Problem Solving with Computers-I

Side note: Tail Recursion. Begin at the beginning. Side note: Tail Recursion. Base Types. Base Type: int. Base Type: int

Transcription:

Generating 3-Address Code from an Attribute Grammar

Here is a small but realistic programming language with integer and boolean data, loops and conditionals, procedures with no arguments that compute but don't return. Procedures can have local procedures. So it isn't everything that you might want, but it isn't completely trivial. We will use an attribute grammar to automatically generate 3- address code for programs in this language.

First, here is a context-free grammar for the language: P ::= program id DECS ; S DECS ::= id : T proc id ( ) DECS; S DECS ; DECS T ::= int bool S ::= id = E if (E) then S else S while (E) do S id ( ) begin S_LIST end S_LIST ::= S S_LIST ; S E ::= id number true false E+E E*E E and E E or E

Here is a program in this language: program foo a: int; b: int; proc add( ) x: int; begin x = a+b+1; a = x end begin a = 1; b = 2; add( ) end

Each procedure has a symbol table containing: a) The name of the procedure b) A pointer to the lexically enclosing procedure c) A pointer to its table of quadruples d) Symbols and temporaries used in the procedure We do the same thing for the whole program; it acts like a standalone procedure.

Here is the symbol table and list of quads for program foo: name foo enclosing nil quads = a 1 a int = b 2 b int call add add proc and for procedure add: name add enclosing foo quads + a b t1 x int + t1 1 x t1 int = x a

We'll make use of the following helper procedures: make_table(name, enclosing_scope) // makes a new symbol table and a new quad table add_to_table(table, name type) // adds a name and type to the symbol table add_proc_to_table(table, name, new_table) // lookup(table, id) // returns a pointer to the id's entry in the symbol table new_temp(table, type) // adds a new temporary variable emit(table, op, arg1, arg2, arg3) // adds a new quad to the table

Attributes We will pass the symbol table down as an inherited attribute. For each expression symbol E, E.place is the address where E is located in the symbol table. T.type is int, boolean

Here is the attribute grammar: P ::= program id {DECS.table= make_table(id.val, nil)} DECS ; {S.table=DECS.table} S // declarations DECS ::= id : T {add_to_table(decs.table, id.val, T.type} proc id ( ) {DECS 1.table=make_table(id.val, DECS.table); add_to_table(decs.table, id.val, DECS 1.table) } DECS 1 ; {S.table=DECS 1.table} S {DECS 1.table=DECS.table} DECS 1 ; {DECS 2.table=DECS.table} DECS 2 T ::= int {T.type=int } bool {T.type=bool}

// expressions E ::= id {p = lookup(e.table, id.val); if (p!= nil) E.place = p else error } number {E.place = new_temp (E.table, int); emit(e.table, =, E.place, number } true {E.place= new_temp(e.table, bool); emit(e.table, =, E.place, true)} false {E.place=new_temp(E.table, bool) emit(e.table, =, E.place, false) } {E 1.table=E.table}E 1 +{E 2.table=E.table} E 2 {E.place=new_temp(E.table, int); emit(e.table, +, E 1.place, E 2.place, E.place) } // other expressions are similar

// statements S ::= id = {E.table=S.table} E {p=lookup(s.table, id.val); if (p == null) error else emit(s.table, =, p, E.place) } id ( ) {p=lookup(s.table, id.val); if (p== null) error else emit(s.table, call, p ) } begin {S_LIST.table=S.table} S_LIST end

S_LIST ::= {S.table=S_LIST.table} S {S_LIST 1.table=S_LIST.table } S_LIST 1 ; {S.table=S_LIST.table} S

We have handled everything but IF and WHILE statements, which require labels. There are two ways to handle labels: pass them around as attributes (which we have done in other examples, or leave space for them and fill them in later. Just for fun, we'll take the latter approach here.

S ::= if {E.table=S.table} E {M 1.table=E.table} M 1 {emit( "if not', E.place, 'goto', ) } then {S 1.table=S.table} S 1 M 2 {emit( 'goto', )} else M 3 {S 2.table=S.table} S 2 {patch(m 1.quad, M 3.quad); patch(m 2.quad, next_quad(s 2.table)} M 1 ::= e {M 1.quad=next_quad(M 1.table)} M 2 ::= e {M 2.quad=next_quad(M 2.table)} M 3 ::= e {M 3.quad=next_quad(M 3.table)} In these rules next_quad(table) is the address of the first free quad in the table. patch(pos, label) puts the label in the given position.