Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

CS 142 Compilers Assignment 2: Writing a Parser for Cool with Abstract Syntax Tree - Prof., Assignments of Computer Science

University of California - DavisComputer Science
Prof. Sean P. Peisert

In this assignment, students will write a parser for the cool programming language using bison or cup, and generate an abstract syntax tree (ast) as output. The parser will be constructed using semantic actions of the parser generator. Students will need to refer to the syntactic structure of cool and use the provided files for testing the parser. The goal is to create a working parser that can handle legal constructions of the grammar and recover from certain types of errors.

Typology: Assignments

Pre 2010

Uploaded on 07/31/2009

koofers-user-wyb
koofers-user-wyb 🇺🇸

9 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS 142 Compilers Handout 2
Programming Assignment II
Due Friday, April 24, 2009 at 11:55 PM
1 Introduction
In this assignment you will write a parser for Cool. The assignment makes use of two tools: the parser
generator (the C++ tool is called bison; the Java tool is called CUP) and a package for manipulating
trees. The output of your parser will be an abstract syntax tree (AST). You will construct this AST
using semantic actions of the parser generator.
You certainly will need to refer to the syntactic structure of Cool, found in Figure 1 of The Cool
Reference Manual (as well as other parts). The documentation for bison and CUP is available online.
There is also a section (Dragon Book 4.9) in the textbook on yacc, a close predecessor of bison. The C++
version of the tree package is described in the Tour of Cool Support Code handout. The documentation
for the Java version is available online. You will need the tree package information for this and future
assignments.
There is a lot of information in this handout, and you need to know most of it to write a working
parser. Please read the handout thoroughly.
You must work in a group for this assignment (where a group consists of one or two people).
2 Files and Directories
To get started, create a directory where you want to do the assignment and execute one of the following
commands in that directory. For the C++ version of the assignment, you should type
gmake -f /home/cs142/s09/cool/assignments/PA3/Makefile
For Java, type:
gmake -f /home/cs142/s09/cool/assignments/PA3J/Makefile
(notice the “J” in the path name). This command will copy a number of files to your directory. Some of
the files will be copied read-only (using symbolic links). You should not edit these files. In fact, if you
make and modify private copies of these files, you may find it impossible to complete the assignment. See
the instructions in the README file. The files that you will need to modify are:
•cool.y (in the C++ version) / cool.cup (in the Java version)
This file contains a start towards a parser description for Cool. The declaration section is mostly
complete, but you will need to add additional type declarations for new nonterminals you introduce.
We have given you names and type declarations for the terminals. You might also need to add
precedence declarations. The rule section, however, is rather incomplete. We have provided some
parts of some rules. You should not need to modify this code to get a working solution, but you are
welcome to if you like. However, do not assume that any particular rule is complete.
Spring 2009 page 1 of 4
pf3
pf4

Partial preview of the text

Download CS 142 Compilers Assignment 2: Writing a Parser for Cool with Abstract Syntax Tree - Prof. and more Assignments Computer Science in PDF only on Docsity!

Programming Assignment II

Due Friday, April 24, 2009 at 11:55 PM

1 Introduction

In this assignment you will write a parser for Cool. The assignment makes use of two tools: the parser generator (the C++ tool is called bison; the Java tool is called CUP) and a package for manipulating trees. The output of your parser will be an abstract syntax tree (AST). You will construct this AST using semantic actions of the parser generator. You certainly will need to refer to the syntactic structure of Cool, found in Figure 1 of The Cool Reference Manual (as well as other parts). The documentation for bison and CUP is available online. There is also a section (Dragon Book 4.9) in the textbook on yacc, a close predecessor of bison. The C++ version of the tree package is described in the Tour of Cool Support Code handout. The documentation for the Java version is available online. You will need the tree package information for this and future assignments. There is a lot of information in this handout, and you need to know most of it to write a working parser. Please read the handout thoroughly. You must work in a group for this assignment (where a group consists of one or two people).

2 Files and Directories

To get started, create a directory where you want to do the assignment and execute one of the following commands in that directory. For the C++ version of the assignment, you should type

gmake -f /home/cs142/s09/cool/assignments/PA3/Makefile

For Java, type:

gmake -f /home/cs142/s09/cool/assignments/PA3J/Makefile

(notice the “J” in the path name). This command will copy a number of files to your directory. Some of the files will be copied read-only (using symbolic links). You should not edit these files. In fact, if you make and modify private copies of these files, you may find it impossible to complete the assignment. See the instructions in the README file. The files that you will need to modify are:

  • cool.y (in the C++ version) / cool.cup (in the Java version)

This file contains a start towards a parser description for Cool. The declaration section is mostly complete, but you will need to add additional type declarations for new nonterminals you introduce. We have given you names and type declarations for the terminals. You might also need to add precedence declarations. The rule section, however, is rather incomplete. We have provided some parts of some rules. You should not need to modify this code to get a working solution, but you are welcome to if you like. However, do not assume that any particular rule is complete.

  • good.cl and bad.cl These files test a few features of the grammar. You should add tests to ensure that good.cl exercises every legal construction of the grammar and that bad.cl exercises as many types of parsing errors as possible in a single file. Explain your tests in these files and put any overall comments in the README file.
  • README As usual, this file will contain the write-up for your assignment. Explain your design decisions, your test cases, and why you believe your program is correct and robust. It is part of the assignment to explain things in text, as well as to comment your code.

To submit your assignment, run “/home/cs142/s09/bin/submit” from your PA3 directory and follow the instructions.

3 Testing the Parser

You will need a working scanner to test the parser. You may use either your own scanner or the coolc scanner. By default, the coolc scanner is used; to change this behavior, replace the lexer executable (which is a symbolic link in your project directory) with your own scanner. Don’t automatically assume that the scanner (whichever one you use!) is bug free—latent bugs in the scanner may cause mysterious problems in the parser. You will run your parser using myparser, a shell script that “glues” together the parser with the scanner. Note that myparser takes a -p flag for debugging the parser; using this flag causes lots of information about what the parser is doing to be printed on stdout. Both bison and CUP produce a human-readable dump of the LALR(1) parsing tables in the cool.output file. Examining this dump is frequently useful for debugging the parser definition. You should test this compiler on both good and bad inputs to see if everything is working. Remember, bugs in your parser may manifest themselves anywhere. Your parser will be graded using our lexical analyzer. Thus, even if you do most of the work using your own scanner you should test your parser with the coolc scanner before turning in the assignment.

4 Parser Output

Your semantic actions should build an AST. The root (and only the root) of the AST should be of type program. For programs that parse successfully, the output of parser is a listing of the AST. For programs that have errors, the output is the error messages of the parser. We have supplied you with an error reporting routine that prints error messages in a standard format; please do not modify it. You should not invoke this routine directly in the semantic actions; bison/CUP automatically invokes it when a problem is detected. Your parser need only work for programs contained in a single file—don’t worry about compiling multiple files.

5 Error Handling

You should use the error pseudo-nonterminal to add error handling capabilities in the parser. The purpose of error is to permit the parser to continue after some anticipated error. It is not a panacea

  • You must declare bison “types” for your non-terminals and terminals that have attributes. For example, in the skeleton cool.y is the declaration:

%type program

This declaration says that the non-terminal program has type . The use of the word “type” is misleading here; what it really means is that the attribute for the non-terminal program is stored in the program member of the union declaration in cool.y, which has type Program. By specifying the type

%type <member_name> X Y Z ...

you instruct bison that the attributes of non-terminals (or terminals) X, Y, and Z have a type appro- priate for the member member name of the union. All the union members and their types have similar names by design. It is a coincidence in the example above that the non-terminal program has the same name as a union member. It is critical that you declare the correct types for the attributes of grammar symbols; failure to do so virtually guarantees that your parser won’t work. You do not need to declare types for symbols of your grammar that do not have attributes. The g++ type checker complains if you use the tree constructors with the wrong type parameters. If you ignore the warnings, your program may crash when the constructor notices that it is being used incorrectly. Moreover, bison may complain if you make type errors. Heed any warnings. Don’t be surprised if your program crashes when bison or g++ give warning messages.

9 Notes for the Java version of the assignment

If you are working on the C++ version, skip this section.

  • You must declare CUP “types” for your non-terminals and terminals that have attributes. For example, in the skeleton cool.cup is the declaration:

nonterminal program program;

This declaration says that the non-terminal program has type program. It is critical that you declare the correct types for the attributes of grammar symbols; failure to do so virtually guarantees that your parser won’t work. You do not need to declare types for symbols of your grammar that do not have attributes. The javac type checker complains if you use the tree constructors with the wrong type parameters. If you fix the errors with frivolous casts, your program may throw an exception when the constructor notices that it is being used incorrectly. Moreover, CUP may complain if you make type errors.