Programming Language Translation
(CSc301)
2008
This course is a module of CSc 301. It introduces students to the theory and practice of writing compilers for imperative programming languages. It also exposes them to elements of formal language theory as this relates to the specification of the syntax and semantics of such languages.
This module is worth 12 credits.
Students must have mastered programming in a high-level language (preferably Java, C# or C++) and have taken a course in data structures and one in simple computer architecture (as covered in the CSC 201 course at this university).
Students will be expected to:
At the conclusion of the course, students should be able to:
Daily lectures are given to present and explain the course content. The lectures follow a comprehensive (published) textbook, developed by the lecturer, and are illustrated with overhead projector slides. PowerPoint is not currently used, nor is there any intention to do so in the near future.
There are weekly practical sessions, which are designed to reinforce the lecture material. There are also voluntary tutorial and workshop sessions for students who need extra assistance in mastering the material.
The course is divided into six main sections. These are detailed here, together with estimates of the number of lectures devoted to each section.
Students are expected to obtain a copy of the comprehensive textbook, developed by the lecturer. As is typical of published textbooks, the bibliography includes an extensive optional reading list. The course website provides links to further on-line resources (such as textbooks) for background reading and support.
At each appropriate point in the presentation of the course the module website is updated to provide detailed solutions to the practical exercises and class tests set up to that point. Such solutions incorporate extra discussion and explanation of material that the lecturer feels some students may have misunderstood. An archive of model solutions to examinations previously set in the course is also maintained on this website, but is withheld from students initially, to combat the temptation to "mine" this resource for solutions and hints to the exercises for the current year. As it is, one has become increasingly aware in recent years that students have access to old solutions and tutorials, and often foolishly submit these in place of the ones required in the current year.
| Specific Outcomes | Assessment Criteria | Assessment Tasks |
|---|---|---|
| 1. understand the role played by compilers and the internal structure of this type of software. | Students can reason about the importance,
advantages and disadvantages of the use of high-level
languages and the necessity for the compilation process.
Students can describe the structure of compilers and are familiar with the terminology used to describe this structure, and with the role played by the components of a compiler. | Students answer qualitative, descriptive questions in tests and examinations on the role and structure of compilers and the properties of high-level languages. |
| 2. understand and apply elements of formal language theory to the description of programming languages. | Students are familiar with the elements of and
the notations for formal language theory (for example,
regular expressions, Chomsky grammars) and can analyse and
synthesize descriptions of syntax-oriented systems (for
example, programming languages) using such notations.
Students can relate formal descriptions of syntax-directed systems to the key phases of scanning (lexical analysis) and parsing (syntax analysis) that are essential to a compiler. | Students construct grammars in practicals to
describe programming languages (and other systems for which
a syntax-directed analysis of data is appropriate) and
investigate their properties and suitability for the
purpose.
Students construct grammars in tests and examinations to describe programming languages (and other systems for which a syntax-directed analysis of data is appropriate) and investigate their properties and suitability for the purpose. |
| 3. understand and be able to implement interpreters for simple virtual computing machines. | Students can describe models of processors and
their execution (e.g. the fetch-execute cycle) in terms
that permit simulation of such processors to be
accomplished by developing emulators that can "execute"
programs written in low-level virtual machine languages.
Students can appreciate and explain situations where interpretation has advantages and disadvantages over native-code generation, and can discuss techniques for improving the efficiency of an emulator. Students can implement an emulator for a simple virtual machine. | Students develop and extend an interpreter for a
virtual machine in practicals, and test this on simple
programs hand-coded into virtual machine code.
Students describe the workings and shortcomings of an interpreter and interpretive execution qualitatively in tests and examinations, and may be asked to describe extensions to such systems in terms of code extracts. |
| 4. use compiler generating tools to develop a compiler for a simple, yet non-trivial, imperative programming language. | Students can accurately describe a compiler for
a simple programming language (or some other
syntax-directed tool), starting from a formal syntactic
description and augmenting this to incorporate classic
phases of the translation process such as error detection
and recovery, the use of symbol tables for semantic
constraint analysis, and code generation (for a virtual
machine of the sort described earlier).
Students can process such formal descriptions with the use of an open-source compiler generator (Coco/R, developed at a university in Austria). | Students construct and/or extend one or more simple
syntax-directed tools (including a complete compiler for a
small programming language) in practicals.
Students extend or modify such tools in tests and examinations (see "Assessment Methods" below). |
The weekly practicals provide students with frequent formative assessment of their progress and understanding. Completed practical assignments are submitted on a group basis for formal assessment. These are marked by the lecturer.
A short test is given on the material of each practical, immediately after it has been submitted. This is marked by the lecturer. Care is take to ensure that the questions are similar in style and difficulty to those that can be expected in the final examination.
A longer formal test, set and marked by the lecturer may be set towards the end of the course if the performance in these short tests suggests that the class would benefit from further testing. In this connection it should be noted that the course normally ends only a few days before the semester-end examination period begins.
All practicals and practical tests are submitted on Thursday and are normally marked by the lecturer and returned to the students by the following Monday.
The final examination in the course is held during the normal set of semester-end examinations written by all students at the University. The examination for this course is set and marked in the first instance by the lecturer. The exam paper is, firstly, moderated ("shredded") internally by a panel of lecturing staff, and, secondly, moderated by the Department's External Examiner. The students' scripts are also sampled by the External Examiner.
The final examination lasts three hours. Approximately half the paper is based on an extended, practically oriented, challenging and hitherto unseen exercise, which is released to the students 24 hours before the start of the examination to allow them to prepare a high-quality solution. Part way through the preparation period further hints may be released to help those who have not understood the question, or are making no progress with it. During the 24 hour period, students may consult references and even other students, but not the demonstrators or staff in the Department. They may not, however, take any material into the final examination session.
Although this form of examination may seem to favour syndication, and even be unreliable because of this, experience has repeatedly shown that a student's own capabilities are readily discernible in the quality of the answers submitted, and the fact that the setting of a challenging question means that the students learn "from" the examination rather then simply "for" the examination means that it achieves far more than is possible with a conventional examination. Great care is taken to prepare an exercise with graded components, so that all students are able to demonstrate their fundamental understanding of the material with confidence, but only the very best can demonstrate that they have appreciated and solved the subtlest aspects of the problem. Lastly, it is worth commenting that the fact that about half of the examination is set in the traditional "unseen" form means that students cannot rely entirely on memorizing a solution to the "seen" question which they might not have devised for themselves.
The formal examination component is made of 180 marks (out of 270 for the semester's formal examination components). Approximately 45%-50% of the formal examination component is allocated to the single large question which is revealed to students 24 hours before the start of the examination
A student's mark for the semester credit course CSC 301 (of which this module forms part) is obtained by weighting the total formal examination components at 67% and the class mark components at 33%.
A summative course evaluation is run during the final week of the course.
The evaluation covers a number of topics, including the lectures, the lecturer, practicals, demonstrators and equipment and facilities. Provision is also made for students to give free-format comments on any aspect of the course.
A summary of the evaluation results is posted on the module website (with reactions and feedback from the lecturer).