CS 453 Programming Assignment #6 — MeggyJava for paddle ball

Due Friday April 15th (by 11:59pm)

Introduction

This assignment is to be done with your CS 453 programming partner. In this assignment you will be writing a program that parses the PA6 subset of the MeggyJava language that includes local and member variable declarations and assignment statements. The main addition in terms of functionality will be handling of classes, local and member variables, the equality operator for integers and references, and the less than operator for integers. You will

add the tokens for the PA6 MeggyJava to the PA5 lexer,
add the PA6 grammar rules to the parser,
and update the code generation visitor to handle the new language features.

You will need to do type checking for method calls, variable declarations, and ...

The Assignment

You should create a jar file, MJPA6_groupname.jar, that can be executed as follows:

   java -jar MJPA6_groupname.jar InputFile.java

The input files can be any PA6 MeggyJava program. The PA6Cylon.java example you wrote for PA2 and PA6PaddleBall.java are possible test cases for MJPA6_groupname.jar. The output file named InputFile.java.s should be an AVR assembly program that using the provided build process will run on the MeggyJr device. Additionally, the InputFile.java.s file must be such that we can run it through the AVR simulator MJSIM.jar (NOTE: this is a new version of MJSIM.jar updated for PA5).

This assignment requires the following implementation strategies be used:

An AST must be built by the parser.
A symbol table should be built with one visitor.
Types should be checked with another visitor. Methods can call other methods that are defined later in the file, thus the separate passes for building the symbol table and checking the types.
The AVR code must be generated by a concrete visitor.

Other than the above, you have complete freedom as long as the result is a working compiler.

Symbol Table

We recommend you create a new package symtable that will include the symbol table and symbol table entry classes. A symbol table entry (STE) for this assignment should contain information about a symbol/variable's base, offset, and type. You will need to create your own STE classes. We recommend have an STE subclass for variables, classes, and methods.

For each method, you will need to store signature information. A method's signature includes information about the types of each of its parameters and its return value. Method and Class STEs should also contain a scope that can then contain local variables or member variables and methods respectively. When a symbol is inserted into the symbol table, it should be inserted into the most current scope (i.e. the method being visited).

Class STEs should also contain a scope that can then contain member variables and methods. Each class also has its own namespace, and therefore different classes can have the same method name in them. This means that the method name will need to be mangled, both when the label is printed and for any calls to that method. We recommend that you extend the method STEs to keep track of a mangled name for the method. The mangled name can be some concatenation of the class name and the method name.

The symbol table data structure should be able to insert and lookup the symbol table entries for symbols and print itself to a dot file. Here is a possible interface:

    STE lookup(String)
    
    void insert(STE)

    void pushScope(String)
    
    void insertAndPushScope(NamedScopeSTE)
    
    void popScope()
    
    void outputDot(...)

See the notes from March 31st for some more ideas about how to design the symbol table.

Building the Symbol Table

The symbol table builder visitor should print out the following error to standard error anytime a symbol is redeclared:

[LINENUM,POSNUM] Redeclared symbol SYMNAME

where LINENUM is the line number for the symbol, POSNUM is the position number for the symbol, and SYMNAME is the symbol name. ALL such errors should be printed to standard error, and at the end of symbol table construction if any such errors are printed then the following error should be printed to standard error and your compiler should exit:

Errors found while building symbol table

As an example, here is the output for PA6dupnameserror.java:

[23,16] Redefined symbol A
[27,17] Redefined symbol run
[40,16] Redefined symbol B
[45,17] Redefined symbol foo
[51,21] Redefined symbol run
[57,7] Redefined symbol A
Errors found while building symbol table

Note that since the reference compiler is provided in jar form, you can compare your output with the output from the reference MJ_PA6.jar. Also note that id tokens (i.e., the Token class) already has line and position information.

Type Checking

Your compiler will need to perform some type checking. The following is a list of error messages that will be expected in addition to the error messages your compiler was expected to handle for PA3 and PA4:

    [LINENUM,POSNUM] Class CLASSNAME does not exist
        // anywhere an id token should be a class name

    [LINENUM,POSNUM] Receiver of method call must be a class type

    [LINENUM,POSNUM] Method METHODNAME does not exist in class type CLASSNAME

    [LINENUM,POSNUM] Invalid type returned from method METHODNAME
        // any method declaration

    [LINENUM,POSNUM] Method METHODNAME does not exist

    [LINENUM,POSNUM] Method METHODNAME requires exactly NUM arguments

    [LINENUM,POSNUM] Invalid argument type for method METHODNAME

    [LINENUM,POSNUM] Undeclared variable VARNAME
        // anywhere an id token could be a variable name

    [LINENUM,POSNUM] Invalid expression type assigned to variable VARNAME
        // assignment statements

where LINENUM is the line number for the symbol, POSNUM is the position number for the symbol, CLASSNAME is a specific class name, METHODNAME is a specific method name, and VARNAME is a specific variable name.

To enable easier testing and grading do not change the phrasing of the error messages. Test against the reference type checkers in ~cs453/public/.

Code Generation

We recommend you have one visitor that annotates the variable symbol table entries with location information and then extend your existing AVR code generator to handle the new language features.

See the Meggy Sim instructions for usage notes. The set of instructions you will need include a file declaration at the top of the assembly file (.file "main.java"), instructions in the previously provided avrH.rtl.s and avrF.rtl.s files and the following:

    # Examples of each statement type are provided.
    # Register numbers, constant values, and labels can change.
    ldi    r24,lo8(1)
    ldi    r25,hi8(0)
    ldi    r24,73
    lds    r24, Button_A

    push   r24
    pop    r24

    call   functionName

    tst    r24    
    cp     r24, r25
    breq   MJ_L6
    brne   MJ_L7
    jmp    MJ_L6
    
    LabelWithAnyName:
    
    # top of a function declaration
    .text
    .global Cloudrain
    .type Cloudrain, @function
Cloudrain:

    # indirect stores and loads
    std    Y+1, r24
    ldd    r24, Y + 3

    call    malloc

For more details about the instructions see the 08-MeggyJrSimple-n-AVR.txt notes.

Notice that avrF.rtl.s already has an infinite loop at the end of main so that the program will always remain running on the Meggy Jr device even if there is no while loop in the MeggyJava program.

Getting Started

The following is a suggested progression for starting this assignment:

Start with your working PA5 compiler.
Clean up some of the issues from previous assignments.
- You will need to use a new version of the ThisExp.java class and the DepthFirstVisitor.java and ReversedDepthFirstVisitor.java. These are needed so that the correct line and positions are computed if the last method in the program returns "this".
- Ensure that all correct type checking is occurring for PA4 additions, byte x byte -> int for sub or add.
- Implement equality checks for integers and references.
- Operands to < operator must be of same type.
Design, implement, and test the symbol table and related classes separately.
Extend your .lex and .cup files for the new grammar features.
Create a build symbol table visitor that collects all of the type information about all of the identifiers in the program. The build symbol table visitor should also be able to print out all duplicate identifier usage in a program.
Extend your type checking visitor to handle type errors related to method definitions, calls, and classes.
Modify your code generator visitor so that it can handle method calls where the first parameter is now a pointer to the receiver object, constructor calls like new Foo(), usage of the implicit "this" variable, access to local and member variables, and assignment statements.

Submitting the Assignment

Make sure you test your implementation thoroughly.
Only turnin one assignment per group.
Create the MJPA6_groupname.jar file that contains all the source code, the .class files, your .cup and .lex files, a README file, and a subversion.txt file. We should be able to use the jar file to run your PA6 MeggyJava compiler. You do NOT have to include MJSIM.jar or the meggy package into your jar file. You will probably have to add filenames to the provided Makefile in the command that creates the jar file.
- The README file should include your usernames, email addresses, joint partner report (see the 07-LL1-Meggy.txt notes), and any information you want the TA to have before grading your assignment ( e.g., this part is not working due to..., any assumptions you had to make due to ambiguity in the specification, a favorite quote or joke to amuse the TA, etc).
- The subversion.txt file should include output from the following:
```
svn log
svn info
svnlook tree REPOSITORY_PATH 
    
```
  Note that svnlook must be issued on the machine where the repository resides.
- Partner report and evaluation. See the 07-LL1-Meggy.txt notes for information about the joint and separate partner reports. Answer all of the required points with full sentences.

Submit assignment using checkin utility.

~cs453/bin/checkin PA6 MJPA6_groupname.jar

Sanity Check (procedure TA will use to grade your assignment):

    
    // We will also run the test cases with different arg_opts files.
    java -jar MJPA6_groupname.jar TestCase.java
    java -jar MJSIM.jar -b -f TestCase.java.s > t1
    javac TestCase.java
    java TestCase > t2
    diff t1 t2
    
    
    // to get the README, subversion.txt, look at source files, 
    // and view any other required files
    jar xf MJPA6_groupname.jar

Late Policy

Late assignments will be accepted up to 48 hours past the due date for a 10% deduction. The assignment will not be accepted past this period. Late means anything after 11:59pm on the day the assignment is due, including 12 midnight.

mstrout@cs.colostate.edu .... March 31, 2011