C431 -- Assemblers and Compilers I -- Fall 1994

Instructor
Christopher Haynes
Associate Instructor
Sanjeev Kumar
Prerequisites
C311, C335, and C343 or equivalent
Credit hours
4
Lecture
Section 1988, MW 11:15-12:30, in BH144
Local newsgroup
ac.c.431
Acknowledgment
This course, especially the projects, is patterned closely on material developed by R. Kent Dybvig.

Outline

Overview

The goal of this course is to give a working knowledge of the basic techniques used in the implementation of modern programming languages. In a series of cumulative projects, students will implement a native-code compiler for a substantial subset of Scheme. Though the semantics of modern languages such as Scheme is generally simpler that that of traditional languages such as C, their efficient implementation more challenging.

The techniques studied in this course are of far broader use than the implementation of general purpose programming languages. Parsing, syntax-directed transduction (structural semantic analysis), and run-time support techniques have application in the implementation of a wide variety of systems. A general knowledge of language implementation technique also allows programmers to better judge the efficiency of language constructs and understand the design of complex languages and their support environments.

Topics include:

C431 and C432 constitute a sequence in the sense that C431 is a prerequisite to C432, and some of the projects in C432 may build on the C431 project, but the two courses are not the unified sequence they once were. C431 may well be taken alone and C432 will be taught this academic year by a different instructor (Dan Friedman).

The word "assemblers" in the course title also reflects bygone days. The course will cover assembly techniques only in so far as they are necessary for compilation.

Texts

Projects

There will be four major projects:
  1. Scheme read procedure: scanning and elementary parsing
  2. Parse alternate Scheme syntax: LL(1) parsing
  3. Intermediate code generation: Scheme to "core" Scheme transformation
  4. Assembly Code generation: includes implement limited run time support.
Links to full project descriptions will appear above as the projects are assigned. File names mentioned in project descriptions are relative to the copper directory /u/chaynes/c431. Projects 1, 3, and 4 (or 2, 3, and 4 if you prefer a non-parenthesized syntax) together implement a substantial subset of Scheme.

Use comments at the beginning of your code to provide an overview of your implementation technique and use occasional comments within code as necessary for clarity. The first line of all submissions should be a comment that includes the project number, your name, and your email address.

Submitted code should not contribute bindings to the top-level name-space other than those named in the project description and bindings with names of the form [set]pn#id, where n is the project number, id is any identifier, and the braces around set indicate that it is optional. This policy is designed to avoid name conflicts and accommodate structure definitions.

One week prior to the due date of each project a file of test data must be submitted in a format that will be specified with each assignment. All submitted test data will be collected and made available to all. Compiled code for a (supposedly) correct solution of each assignment will be provided with the test data along with automated procedures for checking your program against correct solution using the test data.

In evaluation of projects, the first criteria is correctness, judged primarily using these tests. Consideration will also be given to programming style, including algorithm design, appropriate use of standard Scheme facilities, documentation, and appropriate indentation. Your primary concern besides correctness should be the clarity of your code. Efficiency will only be considered on rare occasions when it really matters. Creativity in the creation of test examples is also considered in project evaluation.

Projects are to be done individually. Students are encouraged to consult with one another on matters not related to a project. Any help received that is specific to a project must be credited in comments at the beginning of your submission.

As submitted, all projects must run under Chez Scheme (invoked with the command scheme) on copper, a UCS Alpha-architecture machine. You may do most of your work on machines of your choice and then move your work to copper for final testing and submission. Project 4 object code, however, must be tested on copper (unless you have access to another Alpha machine).

Submit your project source and test data via an email message to sakumar@copper. (Other email communication with Sanjeev should be addressed to sakumar@cs.) All new code written for a project should be included in your submission and any other code, say from prior projects, should be loaded using a complete copper path.

Code developed for a project should be kept protected for one week after the project's due date. Be sure to then unprotected it you load it it in a subsequent project.

Projects will be accepted during a grace period of one week following the project due date. Projects submitted after the grace period will not be graded. Test data will not be accepted after a test data due date.

Communication

The course newsgroup, ac.c.431, will be used to post announcements, such as assignments, exams, and any exceptions to my usual office hours. You are also encouraged to use it to post questions related to the course or share information with the class. Make a habit of looking for new notes every day or two.

This course description is accessible as an HTML (hypertext markup language) file on the WWW (World Wide Web) with the URL (Universal Resource Locator) http://www.cs.indiana.edu/hyplan/chaynes/c431.html. It will be updated with additional information as the course progresses.

To view a resource given its URL, use the Unix command Mosaic URL. Mosaic underlines HTML hypertext links. To follow a link, click on it. This may be used, for example, to obtain information on the instructor and associate instructor (see the beginning of this document, or the signature at the end) such as office hours and phone numbers, or to access the course newsgroup. If Mosaic is used for newsgroup access, you should set the shell variable NNTPSERVER to a suitable server other than the net server, such as grouchy.cs.indiana.edu. Invoking Mosaic with no arguments will display the department's or university's home page, depending on who owns the machine running Mosaic. Everyone is encouraged to join the department's Web by creating a personal hyplan file. The department's home page provides links to pages describing how to create a hyplan file and other Web-related information.

Policies

Evaluation

Course evaluation will be based primarily on a mid-term exam, final exam, and programming projects. Class participation and written assignments may also be considered.

Academic Integrity

See the Computer Science Department policy statement. Non-original research results and their sources must be credited, as is expected in the technical literature.

Withdrawal and Incomplete Grades

Withdrawal after Wednesday, October 26th, requires concurrence of the dean based on extenuating circumstances.

An incomplete (I) final grade will be given only by prior arrangement in exceptional circumstances conforming to university and departmental policy in which the bulk of course work has been completed in passing fashion.

chaynes@indiana.edu