Syllabus: CS541, Compiler Design, Fall 2021

CS541 is an course covering many aspects of compiling programming languages. It covers both the theory and practice of compiler-writing tools, such as lexical analyzers and parser generators, as well as symbol tables, runtime organization for simple and structured variables, and code generation. As a prerequisite, you should be adept in programming in a modern programming language (you will complete all assignments in Java) and have knowledge of machine organization (you will compile for the Java Virtual Machine, which we will describe in class).

You will complete a five-stage project that creates a comprehensive compiler (symbol table, lexical analyzer, parser, semantic checker, and code generator).

The first half of the class is devoted to lectures on the theory of scanning and parsing. The second half deals with practical matters of building a compiler. Each class session will present an oddity of Java.

Learning Outcomes

By the end of the course, you will be able to:

• apply knowledge of computing and mathematics appropriate to the discipline
• apply design and development principles in the construction of software systems of varying complexity
• specify lexical and syntactical structure of languages
• use regular patterns and grammars
• use parsing and translation techniques for automation of computing tasks
• use tools to generate lexical analyzers, parsers, translators and code generators
• organize runtime storage for static and dynamic objects
• design and write a complex programming project

Times and places

Class 
MWF 2pm ‒ 2:50p Robotics & Manufacturing 309
Instructor 
Raphael Finkel
Web 
http://www.cs.uky.edu/~raphael/courses/CS541.html
E-mail 
raphael @cs.uky.edu
Office 
Hardymon 230 (7-3885); Zoom 581609732
Office hours: 
T 10a-11:30a, Th 2p-3:30p

Assignments

There are five programming assignments corresponding to five stages of a compiler. All are based on a version of CSX (Computer Science eXperimental). Professor Charles Fischer, the author of our textbook, designed the original CSX language and the assignments.

I encourage you to use the machines in the MultiLab on the second floor of the Engineering Annex (https://www.cs.uky.edu/docs/users/multilab.html). The tools you need are available there. You automatically get a class account at the MultiLab. You need to use a secure shell to contact these computers from elsewhere; you can use ssh from Unix, Mac, or Windows, or putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) from Windows. If you use a secure shell to access the MultiLab, it is best to connect to penstemon.cs.uky.edu or coreopsis.cs.uky.edu. You need to use the University VPN (virtual private network) to connect (https://www.uky.edu/its/phone-internet-services/connecting-vpn) from off-campus. You may construct your programs on any computer you wish, but they must run properly on Linux in the MultiLab.

You must complete your assignments in Java.

Schedule

The following is approximate.

Week 
Date 
M 
W 
F
1 
Aug 23 
1 
1 
2
2 
Aug 30 
2 
3 
3
3 
Sep  6 
n 
r 
3a
4 
Sep 13  
4 
4 
4
5 
Sep 20 
4 
r 
4
6 
Sep 27 
5 
r 
5b
7 
Oct  4 
5 
5 
m
8 
Oct 11  
M 
6 
6
9 
Oct 18 
7 
7 
7c
10 
Oct 25 
n 
7 
7
11 
Nov 1 
8 
8 
8
12 
Nov 8 
9 
9 
9d
13 
Nov 15 
9 
9 
9
14 
Nov 22 
10 
n 
n
15 
Nov 29 
10 
11 
11e
16 
Dec 6 
12 
12g 
n
 
Dec 15  
 
f

Code 
Meaning
1‒12 
Chapters in book
a 
Symbol table due
b 
Scanner due
c 
Parser due
d 
Semantics checker due
e 
Code generator due
g 
Last day to turn in assignments
n 
No class - Academic holiday
r 
No class - Religious holiday
m 
Midterm exam
M 
Discuss midterm exam
f 
Final exam Wed Dec. 15 3:30 pm - 5:30 pm

References

The text for the course is Charles N. Fischer, Ron K. Cytron, and Richard J. LeBlanc, Jr, Crafting a Compiler Addison-Wesley ISBN 978-0-13-606705-4, 2010.

There are many other good books on compiler construction, including:

1. Aho, Sethi, Ullman, Compilers: Theory and Practice, Addison-Wesley, 1990. A classic.
2. Michael L. Scott, Programming Language Pragmatics, Fourth Edition, Morgan Kaufmann, 2016

Grading

You will be graded 50% on programs (each worth 10%) and 50% on the tests (20% and 30%, with the larger weight on whatever test you do better on). The final will only cover material in the course presented after the midterm. You are not graded on class attendance, but you really need to attend class.

Our accreditation association and the policy of the Graduate School require that there be different assignments and grading criteria for undergraduate students and graduate students in 400G and 500-level courses. Let me know if you need to be considered a graduate student (in particular, if you are a USP student).

For programs, correctness is an important criterion, but is by no means the whole story. Grades on programs are based on

• Program behavior. Not only should your program work right on normal or typical input, adhering to the specifications of the assignment, but it should also show correct behavior in extreme or unusual situations. It should make a reasonable recovery from unusual or incorrect inputs or from internal bugs.
• Method. Your program should use appropriate data structures and algorithms. It should avoid unnecessarily inefficient algorithms, but efficiency should never be pursued at the expense of clarity.
• Internal documentation. Your program should include documentation for someone who wants to modify your program, explaining how it fits together and how the various parts do their job. This documentation can be in the code itself or in a separate file.
• External documentation. Your program should come with a guide to someone who wants to compile and use the program, explaining what it is meant to do, how to compile the program, and how to use it. This documentation is usually in a separate file.
• Quality of test data. Your submittal should come with test data that thoroughly exercise the code. The documentation should describe the expected results of running the program with those test data. Make sure the tests thoroughly exercise the program and explore are unusual cases.
• Presentation. Your English, whether in comments or in other documentation, should be legible, grammatical, and correctly punctuated and spelled. Read
  http://www.cs.uky.edu/~raphael/writing.html for guidance. Run all code and documentation through a spelling checker such as ispell.
• Programming standards. Look at
  http://www.cs.uky.edu/~raphael/checklist.html for suggestions on programming standards, and http://www.cs.uky.edu/~raphael/programming.html for techniques specific to a few languages.

Extra credit is available on all programs. Don't attempt extra work until you have the basic assignment ready to hand in. Extra credit is only be used after initial final grades are assigned to raise grades that are close to borderlines.

Late penalty

Late programs are penalized 3% for each day late, starting at noon time on the due date (always Friday), but not including weekends or holidays. (Allowances for computer failure are announced in class and by the class mailing list.) The maximum penalty is 7 days late; after that, you may hand in the program and still get 79% until the absolute deadline: Wednesday noon of the last week of classes. No extra credit is available on late programs. If you turn in a program early, you gain early credits (which also ignore weekends and holidays), which are only used to offset late penalties on other assignments but have no other value.

How to submit programs

Submit all work electronically. Collect all the files in your assignment (including program, documentation, test data, and output, into a single file (you may use shar, rar, zip, gzip, bzip2, or tar) and submit it via Canvas.

Responsible use of computers

You are expected to use the computing facilities on campus in accordance with standards of honesty and personal conduct. Those standards, outlined in the University of Kentucky Policy governing access to and use of University of Kentucky computing resources , available at https://www.uky.edu/regs/sites/www.uky.edu.regs/files/files/ar/ar10-1_2018_final.pdf, call for all members of the community to act in a responsible, ethical, and professional way. This note offers guidelines in applying those standards to use of these facilities.

The operating systems used by our facilities encourage sharing of information. Security mechanisms for protecting information from unintended access, from within the system or from the outside, are minimal. These mechanisms, by themselves, are not sufficient for a large community in which protection of individual privacy is as important as sharing. Users must supplement the system's security mechanisms by using the system in a manner that preserves the privacy of others.

For example, users should not attempt to gain access to the files or directories of another user without clear authorization from the other user (typically that authorization is expressed by setting file access permissions to allow public or group reading). Nor should users attempt to intercept any network communications, such as electronic mail or user-to-user dialog. A shared program should not secretly collect information about its users. Personal information about individuals, which a user would not normally disseminate, should not be stored or communicated on the system. Examples of such personal information are grades or letters of recommendation.

Actions taken by users intentionally to interfere with or to alter the integrity of the system are out of bounds. Such actions include unauthorized use of accounts, impersonation of other individuals in communications, attempts to capture or crack passwords or encryption, and destruction or alteration of data or programs belonging to other users. Equally unacceptable are intentional efforts to restrict or deny access by legitimate users to the system.

Plagiarism

The assignments for this class are similar to ones assigned in previous semesters. You may not refer to any work submitted or published (on github, for example) by previous students. All academic work, written or otherwise, that you submit is expected to be the result of your own thought, research, or self-expression. You may certainly discuss the programs with each other, but you must not show each other your code; everyone must develop the code completely independently. It is a serious offense to allow other students to copy your work or to copy the work of other students (even if it is in a public computer file or the Internet). If you borrow ideas, algorithms, wording, or code from other sources, you must acknowledge that fact or you have committed plagiarism. If you directly take more than about 4 words in a row from any source, you must indicate that you have done so, typically with a footnote or an in-line citation, using indentation or quote marks to set off the quoted text. (I took some of this text years ago from an online plagiarism guide.)  I punish offenses against this policy quite strictly.

Boilerplate

Students are expected to follow University policy regarding Covid safety requirements. The material in https://www.uky.edu/universitysenate/acadpolicy, https://www.uky.edu/universitysenate/ao, and https://www.uky.edu/universitysenate/student-resources is included here by reference.