Project 2 CISC 471 Compiler Design A Syntax-directed Translator for a Small Imperative Language (SIL-K) Deliverables and Deadlines: April 30 first deliverable. May 6 second deliverable. See below for more details. You may work by yourself or in pairs. Project Objectives: To gain experience writing a syntax-directed translator and learn how to read and modify someone else’s software. Procedure: Write an SDT (syntax-directed translator) to generate code for the simple imperative language shown below, called SIL-K. The SIL-K language does not contain any procedures, but only a single main program. Base types are limited to integer only. Arrays are one-dimensional (or 2-dimensional for extra credit!) with the integer type as its component and index type. The following statements are included: for-do, if-then, if-then-else, assignment, write, and compound statement. Operators are restricted to arithmetic and relational. The grammar that we are using for the SIL-K language is as follows: start ::= program ID ; block . block ::= variables cmpdstmt variables ::= var vardcls | empty string vardcls ::= vardcls vardcl ; | vardcl ; vardcl ::= IDlist : type type ::= integer | array[ ICONST ] of integer | array[ ICONST, ICONST ] of integer IDlist ::= IDlist , ID | ID stmtlist ::= stmtlist ; stmt | stmt stmt ::= ifstmt | fstmt | astmt | writestmt | cmpdstmt cmpdstmt ::= begin stmtlist end writestmt ::= writeln ( exp ) ifstmt ::= ifhead then stmt else stmt | ifhead then stmtifhead ::= if condexp fstmt ::= for ctrlexp do stmt ctrlexp ::= ID := ICONST, ICONST astmt ::= lhs := exp lhs ::= ID | ID [ exp ] | ID [ exp, exp ] exp ::= exp + exp | exp - exp | exp * exp | ID | ID [ exp ] | ID [ exp, exp ] | ICONST condexp ::= exp != exp | exp == exp | exp < exp | exp <= exp You may assume that the SIL-K programs are correct in terms of static semantics, i.e., no semantic analysis (type checking) is required. You will write a syntax-directed translation scheme that will generate ILOC code for the above language. ILOC is an intermediate language that is similar to assembly code. You may test the correctness of your generated ILOC code by running it on the ILOC simulator sim provided in directory /usa/Pollock/cis471/project2 on orioles. This directory also contains the source code of the ILOC simulator if you want to compile it on another machine for testing. Code Shape Requirements * Your code should use the register-register model that exposes the maximal opportunities for register allocation. In other words, each new value should reside in a separate virtual register. The function NextRegister will return a new (fresh) register number each time it is called. * The first element of an array a is a[0] ( one-dimensional) or a[0,0] (two-dimensional). All addresses are byte addresses and an integer value is stored in a 4 byte word. The data layout for two-dimensional arrays should be column-major order. The overall available memory is set to 20,000 bytes. For instance, if you specify array x[100,100] of integer , the simulator will complain! Again, 2-dimensional array translation is extra credit, and not required. * All variables are statically allocated, i.e., there is no need for activation records on a runtime stack. The static area starts at memory location 1024. Addresses above are reserved for register spilling. The register r0 should contain the starting address (namely 1024) of the static area during program execution. * You may only use the following ILOC instructions. All these instructions are implemented in sim , our ILOC simulator. A table of ILOC instructions and their semantics is given at the end of this document.- no operation: nop . - arithmetic: addI, add, subI, sub, mult . - memory load, loadI, loadAO, loadAI, store, storeAO, storeAI . - control flow: br, cbr, cmp_LT, cmp_LE, cmp_EQ, cmp_NE, cmp_GT, cmp_GE . - I/O: output . Please see files instrutil.h and instrutil.c for the definitions of procedures/functions emit, emitComment, NextRegister, and NextLabel. * You may want to generate nop instructions as targets of branches and conditional branches, e.g., L1: nop . * The evaluation of an exp will always result in an integer value, while the evaluation of a condexp will always result in a boolean (0 or 1) value. An ILOC cmp_ instruction writes a boolean value into its target register. * The function NextLabel will generate a new (fresh) label each time it is called. How To Get Started The following code is provided as a starting point for your project. You can copy the files from the directory /usa/Pollock/cis471/project2 on orioles. 1. Scanner: scan.l (flex) *** DO NOT MODIFY *** 2. Parser/Code Generator: parse.y (bison). Here is where most of your code will go. It contains an example of how to use procedure emit to generate code. You will need to remove this in your final version, i.e., it has only be inserted as an illustration example. 3. attr.h and attr.c . You will need to define new attribute(s) for recording information as you parse to use it later in parsing for generating code. 4. symtab.h and symtab.c . May need to be modified. 5. instrutil.h and instrutil.c . Need not modify. 6. Makefile Need not modify. In order to get started on testing your compiler, you can use the following test cases. This is just a tentative list of source codes and their generated sample ILOC code using our code generator sample solution (codegen found in /usa/pollock/cis471/project2 on orioles). We will use many more test cases to grade your project . There are many ways of generating correct code, so our codegen compiler gives you only an overall idea what needs to be done.1. Basic straight line (no conditionals or loops) code: * demo1 ( demo1.out ) 2. Basic code with control flow: * demo2 ( demo2.out ) * demo3 ( demo3.out ) 3. Basic code with control flow and array references: * demo4 ( demo4.out ) * demo5 ( demo5.out ) * demo6 ( demo6.out ) 4. More code with control flow and array references: * demo7 ( demo7.out ) * demo8 ( demo8.out ) You can generate an executable called codegen by typing make. The parser/code generator expects the input on stdin, i.e., you can call the parser on an input program as follows: codegen <