►CMSC 430:   Design and Implementation of Programming Languages
▼Assignments
►Assignment 3:   Primitives, Conditionals, and Dispatch
On this page:
More primitives
Conditional Evaluation with Cond
Dispatching Evaluation with Case
A Leg Up on Parsing
Testing
Rubric
Submitting
8.6
    contents  ← prev  up  next → 

Assignment 3: Primitives, Conditionals, and Dispatch

Due: Thu, Sept 29, 11:59PM

The goal of this assignment is to extend the parser, interpreter, and compiler with some simple unary numeric and boolean operations and two forms of control flow expressions: cond-expressions and case-expressions.

You are given a starter compiler based on the Dupe language we studied in class. The source code is available for download on ELMS and on GRACE. On GRACE, the dupe-plus.zip file can be found in:

/afs/glue.umd.edu/class/fall2022/cmsc/430/0101/public/

You are tasked with extending the language in a number of ways:

You may use any a86 instructions you’d like, however it is possible to complete the assignment using Cmp, Je, Jg, Jmp, Label, Mov, and Sub.

More primitives

Add the following forms of expression to the language:

There are many ways to implement these at the assembly level. You should try implementing these using the limited a86 instruction set.

To do this, you should:

  • Study ast.rkt and the new forms of expression (i.e. new AST nodes) then update the comment at the top describing what the grammmar should look like.

  • Study parse.rkt and add support for parsing these expressions. (See A Leg Up on Parsing for guidance.)

  • Update interp-prim.rkt and interp.rkt to correctly interpret these expressions.

  • Make examples of these primitives and potential translations of them to assembly.

  • Update compile.rkt to correctly compile these expressions.

  • Check your implementation by running the tests in test/all.rkt.

Conditional Evaluation with Cond

The Dupe language we studied included a simple form of performing conditional evaluation of sub-expressions:

(if e0 e1 e2)

However, in the original paper on Lisp, Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I, John McCarthy introduced a generalization of if called “conditional expressions,” which we could add to our language with the following syntax:

(cond [e-p1 e-a1]
      ...
      [else e-an])

A cond expression has any number of clauses [e-pi e-ai] ..., followed by an “else” clause [else en]. For the purposes of this assignment, we will assume every cond expression ends in an else clause, even though this is not true in general for Racket. The parser should reject any cond-expression that does not end in else.

The meaning of a cond expression is computed by evaluating each expression e-pi in order until the first one that does not evaluate to #f is found, in which case, the corresponding expression e-ai is evaluated and its value is the value of the cond expression. If no such e-pi exists, the expression e-an’s value is the value of the cond.

Your task is to extend Dupe with this (restricted) form of cond.

To do this, you should:

Dispatching Evaluation with Case

Racket has a mechanism for dispatching between a number of possible expressions based on a value, much like C’s notion of a switch-statement. This is the case-expression, which we could add to our language with the following syntax:

(case ev
      [(d1 ...) e1]
      ...
      [else en])

The meaning of a case expression is computed by evaluating the expression ev and then proceeding in order through each clause until one is found that has a datum di equal to ev’s value. Once such a clause is found, the corresponding expression ei is evaluated and its value is the value of the case expression. If no such clause exists, expression en is evaluated and its value is the value of the case expression.

Note that each clause consists of a parenthesized list of datums, which in the setting of Dupe means either integer or boolean literals.

Your task is to extend Dupe with this (restricted) form of case.

To do this, you should:

A Leg Up on Parsing

In the past, designing the AST type and structure definitions has given students some grief. Getting stuck at this point means you can’t make any progress on the assignment and making a mistake at this level can cause real trouble down the line for your compiler.

For that reason, let us give you a strong hint for a potential design of the ASTs and examples of how parsing could work. You are not required to follow this design, but you certainly may.

Here’s a potential AST definition for the added primitives, cond, and case:

; type Expr =
; ...
; | (Cond [Listof CondClause] Expr)
; | (Case Expr [Listof CaseClause] Expr)
 
; type CondClause = (Clause Expr Expr)
; type CaseClause = (Clause [Listof Datum] Expr)
 
; type Datum = Integer | Boolean
 
; type Op =
; ...
; | 'abs | '- | 'not
 
(struct Cond (cs e)    #:prefab)
(struct Case (e cs el) #:prefab)
(struct Clause (p b)   #:prefab)

There are two new kinds of expression constructors: Cond and Case. A Cond AST node contains a list of cond-clauses and expression, which the expression of the else clause. Each cond-clause is represented by a Clause structure containing two expressions: the right-hand-side of the clause which is used to determine whether the left-hand-side is evaluated, and the left-hand-side expression.

The Case AST node contains three things: an expression that is the subject of the dispatch (i.e. the expression that is evaluated to determine which clause should be taken), a list of case-clauses (not to be confused with cond-clauses), and an else-clause expression. Each case-clause, like a cond-clause, consists of two things. Hence we re-use the Clause structure, but with different types of elements. The first element is a list of datums, each being either an integer or a boolean.

Now, we won’t go so far as to give you the code for parse, but we can give you some examples:

Testing

You can test your code in several ways:

Note that only a small number of tests are given to you, so you should write additional test cases.

Rubric

The autograder will grade based on these eight components:

Handwritten Tests (proportionally graded)

Randomized Property Testing (must pass all the associated tests for each property)

Submitting

You should submit on Gradescope. You should submit a zip file with exactly the same structure that the stub contains (a dupe-plus folder). We will only use the parse.rkt, ast.rkt, compile.rkt, interp.rkt, and interp-prim.rkt files for grading, so make sure all your work is contained there! The autograder will fail if it does not contain a dupe-plus folder with these files or there is a syntax error.

    contents  ← prev  up  next →