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

Programming Assignment 2 - Compilers - Fall 2005 | ECS 142, Assignments of Computer Science

University of California - DavisComputer Science

Material Type: Assignment; Class: Compilers; Subject: Engineering Computer Science; University: University of California - Davis; Term: Winter 2005;

Typology: Assignments

Pre 2010

Uploaded on 07/31/2009

koofers-user-wr9
koofers-user-wr9 🇺🇸

10 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ECS 142 Compilers Handout 2
Programming Assignment II
Due Tuesday, January 25, 2005 at 11:59pm
1 Overview
Programming assignments II–V will direct you to design and build a compiler for Cool. Each assignment
will cover one component of the compiler: lexical analysis, parsing, semantic analysis, and code generation.
Each assignment will ultimately result in a working compiler phase which can interface with other phases.
You will have an option of doing your projects in C++ or Java.
For this assignment, you are to write a lexical analyzer, also called a scanner, using a lexical analyzer
generator. (The C++ tool is called flex; the Java tool is called jlex.) You will describe the set of tokens
for Cool in an appropriate input format, and the analyzer generator will generate the actual code (C++
or Java) for recognizing tokens in Cool programs.
On-line documentation for all the tools needed for the project will be made available on the CS142
web site. This includes manuals for flex and jlex (used in this assignment), the documentation for bison
and java cup (used in the next assignment), as well as the manual for the spim simulator.
You may work either individualy or in pairs for this assignment.
You may work in a group for this assignment (where a group consists of one or two people). The
submit program will ask you to specify group members when you turn in your assignment.
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/cool/assignments/PA2/Makefile
Note that even though this is the first programming assignment, the directory name is PA2. Future
assignments will also have directories that are one more than the assignment number–please don’t get
confused! This situation arises because we are skipping the usual first assignment in this offering of the
course. For Java, type:
gmake -f /home/cs142/cool/assignments/PA2J/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.flex (in the C++ version) / cool.lex (in the Java version)
This file contains a skeleton for a lexical description for Cool. There are comments indicating where
you need to fill in code, but this is not necessarily a complete guide. Part of the assignment is for you
to make sure that you have a correct and working lexer. Except for the sections indicated, you are
welcome to make modifications to our skeleton. You can actually build a scanner with the skeleton
description, but it does not do much. You should read the flex/jlex manual to figure out what this
description does do. Any auxiliary routines that you wish to write should be added directly to this
file in the appropriate section (see comments in the file).
Winter 2005 page 1 of 5
pf3
pf4
pf5

Partial preview of the text

Download Programming Assignment 2 - Compilers - Fall 2005 | ECS 142 and more Assignments Computer Science in PDF only on Docsity!

Programming Assignment II

Due Tuesday, January 25, 2005 at 11:59pm

1 Overview

Programming assignments II–V will direct you to design and build a compiler for Cool. Each assignment will cover one component of the compiler: lexical analysis, parsing, semantic analysis, and code generation. Each assignment will ultimately result in a working compiler phase which can interface with other phases. You will have an option of doing your projects in C++ or Java. For this assignment, you are to write a lexical analyzer, also called a scanner, using a lexical analyzer generator. (The C++ tool is called flex; the Java tool is called jlex.) You will describe the set of tokens for Cool in an appropriate input format, and the analyzer generator will generate the actual code (C++ or Java) for recognizing tokens in Cool programs. On-line documentation for all the tools needed for the project will be made available on the CS web site. This includes manuals for flex and jlex (used in this assignment), the documentation for bison and java cup (used in the next assignment), as well as the manual for the spim simulator. You may work either individualy or in pairs for this assignment. You may work in a group for this assignment (where a group consists of one or two people). The submit program will ask you to specify group members when you turn in your assignment.

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/cool/assignments/PA2/Makefile

Note that even though this is the first programming assignment, the directory name is PA2. Future assignments will also have directories that are one more than the assignment number–please don’t get confused! This situation arises because we are skipping the usual first assignment in this offering of the course. For Java, type:

gmake -f /home/cs142/cool/assignments/PA2J/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.flex (in the C++ version) / cool.lex (in the Java version) This file contains a skeleton for a lexical description for Cool. There are comments indicating where you need to fill in code, but this is not necessarily a complete guide. Part of the assignment is for you to make sure that you have a correct and working lexer. Except for the sections indicated, you are welcome to make modifications to our skeleton. You can actually build a scanner with the skeleton description, but it does not do much. You should read the flex/jlex manual to figure out what this description does do. Any auxiliary routines that you wish to write should be added directly to this file in the appropriate section (see comments in the file).
  • test.cl This file contains some sample input to be scanned. It does not exercise all of the lexical specification, but it is nevertheless an interesting test. It is not a good test to start with, nor does it provide adequate testing of your scanner. Part of your assignment is to come up with good testing inputs and a testing strategy. (Don’t take this lightly—good test input is difficult to create, and forgetting to test something is the most likely cause of lost points during grading.) You should modify this file with tests that you think adequately exercise your scanner. Our test.cl is similar to a real Cool program, but your tests need not be. You may keep as much or as little of our test as you like.
  • README This file contains detailed instructions for the assignment as well as a number of useful tips. You should also edit this file to include the write-up for your project. You should explain design decisions, why your code is correct, and why your test cases are adequate. It is part of the assignment to clearly and concisely explain things in text as well as to comment your code.

Although these files are incomplete as given, the lexer does compile and run (gmake lexer).

3 Scanner Results

You should follow the specification of the lexical structure of Cool given in Section 10 and Figure 1 of the Cool manual. Your scanner should be robust—it should work for any conceivable input. For example, you must handle errors such as an EOF occurring in the middle of a string or comment, as well as string constants that are too long. These are just some of the errors that can occur; see the manual for the rest. You must make some provision for graceful termination if a fatal error occurs. Core dumps or uncaught exceptions are unacceptable.

3.1 Error Handling

All errors should be passed along to the parser. You lexer should not print anything. Errors are com- municated to the parser by returning a special error token called ERROR. (Note, you should ignore the token called error [in lowercase] for this assignment; it is used by the parser in PA3.) There are several requirements for reporting and recovering from lexical errors:

  • When an invalid character (one that can’t begin any token) is encountered, a string containing just that character should be returned as the error string. Resume lexing at the following character.
  • If a string contains an unescaped newline, report that error as ‘‘Unterminated string constant’’ and resume lexing at the beginning of the next line—we assume the programmer simply forgot the close-quote.
  • When a string is too long, report the error as ‘‘String constant too long’’ in the error string in the ERROR token. If the string contains invalid characters (i.e., the null character), report this as ‘‘String contains null character’’. In either case, lexing should resume after the end of the string. The end of the string is defined as either 1. the beginning of the next line if an unescaped newline occurs after these errors are encountered; or

4 Notes for the C++ Version of the Assignment

If you are working on the Java version, skip to the following section.

  • Each call on the scanner returns the next token and lexeme from the input. The value returned by the function cool yylex is an integer code representing the syntactic category (e.g., integer literal, semicolon, if keyword, etc.). The codes for all tokens are defined in the file cool-parse.h. The second component, the semantic value or lexeme, is placed in the global union cool yylval, which is of type YYSTYPE. The type YYSTYPE is also defined in cool-parse.h. The tokens for single character symbols (e.g., “;” and “,”) are represented just by the integer (ASCII) value of the character itself. All of the single character tokens are listed in the grammar for Cool in the Cool manual.
  • For class identifiers, object identifiers, integers, and strings, the semantic value should be a Symbol stored in the field cool yylval.symbol. For boolean constants, the semantic value is stored in the field cool yylval.boolean. Except for errors (see below), the lexemes for the other tokens do not carry any interesting information.
  • We provide you with a string table implementation, which is discussed in detail in A Tour of the Cool Support Code and in documentation in the code. For the moment, you only need to know that the type of string table entries is Symbol.
  • When a lexical error is encountered, the routine cool yylex should return the token ERROR. The semantic value is the string representing the error message, which is stored in the field cool yylval.error msg (note that this field is an ordinary string, not a symbol). See the previous section for information on what to put in error messages.

5 Notes for the Java Version of the Assignment

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

  • Each call on the scanner returns the next token and lexeme from the input. The value returned by the method CoolLexer.next token is an object of class java cup.runtime.Symbol. This object has a field representing the syntactic category of a token (e.g., integer literal, semicolon, the if keyword, etc.). The syntactic codes for all tokens are defined in the file TokenConstants.java. The component, the semantic value or lexeme (if any), is also placed in a java cup.runtime.Symbol object. The documentation for the class java cup.runtime.Symbol as well as other supporting code is available on the course web page. Examples of its use are also given in the skeleton.
  • For class identifiers, object identifiers, integers, and strings, the semantic value should be of type AbstractSymbol. For boolean constants, the semantic value is of type java.lang.Boolean. Except for errors (see below), the lexemes for the other tokens do not carry any interesting information. Since the value field of class java cup.runtime.Symbol has generic type java.lang.Object, you will need to cast it to a proper type before calling any methods on it.
  • We provide you with a string table implementation, which is defined in AbstractTable.java. For the moment, you only need to know that the type of string table entries is AbstractSymbol.
  • When a lexical error is encountered, the routine CoolLexer.next token should return a java cup.runtime.Symbol object whose syntactic category is TokenConstants.ERROR and whose semantic value is the error message string. See Section 3 for information on how to construct error messages.

6 Testing the Scanner

There are at least two ways that you can test your scanner. The first way is to generate sample inputs and run them using lexer, which prints out the line number and the lexeme of every token recognized by your scanner. The other way, when you think your scanner is working, is to try running mycoolc to invoke your lexer together with all other compiler phases (which we provide). This will be a complete Cool compiler that you can try on the sample programs and your program from Assignment I.

7 What to Turn In

When you are ready to turn in the assignment, type gmake submit-clean in the directory where you have prepared your assignment. This action will remove all the unnecessary files, such as object files, class files, core dumps, Emacs autosave files, etc. Following gmake submit-clean, type submit PA2 or submit PA2J and follow the directions. The last submission you do will be the one graded. Each submission overwrites the previous one. Remember that there is a 0.5% penalty per hour for late assignments. The burden of convincing us that you understand the material is on you. Obtuse code, output, and write-ups will have a negative effect on your grade. Take the extra time to clearly (and concisely!) explain your results.