Description
CMSC 430 Project 3
The third project involves modifying the attached interpreter so that it interprets programs for the
complete language.
You may convert all values to double values, although you can maintain their individual types if
you wish.
When the program is run on the command line, the parameters to the function should be supplied
as command line arguments. For example, for the following function header of a program in the
file text.txt:
function main a: integer, b: integer returns integer;
One would execute the program as follows:
$ ./compile < test.txt 2 4
In this case, the parameter a would be initialized to 2 and the parameter b to 4.
An example of a program execution is shown below:
$ ./compile < test.txt 2 4
1 function main a: integer, b: integer returns integer;
2 c: integer is
3 if a > b then
4 a rem b;
5 else
6 a ** 2;
7 endif;
8 begin
9 case a is
10 when 1 => c;
11 when 2 => (a + b / 2 – 4) * 3;
12 others => 4;
13 endcase;
14 end;
Compiled Successfully
Result = 0
After the compilation listing is output, the value of the expression which comprises the body of
the function should be displayed as shown above.
The existing code evaluates some of the arithmetic, relational and logical operators together with
the reduction statement and integer literals only. You are to add the necessary code to include all
of the following:
Real and Boolean literals
All additional arithmetic operators
All additional relational and logical operators
Both if and case statements
Functions with multiple variables
Functions with parameters
This project requires modification to the bison input file, so that it defines the additional the
necessary computations for the above added features. You will need to add functions to the
library of evaluation functions already provided in values.cc. You must also make some
modifications to the functions already provided.The fourth project involves modifying the semantic analyzer for the attached compiler by adding
checks for semantic errors. The static semantic rules of this language are the following:
Variables and parameter names have local scope. The scope rules require that all names be
declared and prohibit duplicate names within the same scope. The type correspondence rules are
as follows:
Boolean expressions cannot be used with arithmetic or relational operators.
Arithmetic expressions cannot be used with logical operators.
Reductions can only contain numeric types.
Only integer operands can be used with the remainder operator.
The two statements in an if statement must match in type. No coercion is performed.
All the statements in a case statement must match in type. No coercion is performed.
The type of the if expression must be Boolean.
The type of the case expression must be Integer
A narrowing variable initialization or function return occurs when a real value is being
forced into integer. Widening is permitted.
Boolean types cannot be mixed with numeric types in variable initializations or function
returns.
Type coercion from an integer to a real type is performed within arithmetic expressions.
You must make the following semantic checks. Those highlighted in yellow are already
performed by the code that you have been provided, although you are must make minor
modifications to account for the addition of real types and the need to perform type coercion and
to handle the additional arithmetic and logical operators.
Using Boolean Expressions with Arithmetic Operator
Using Boolean Expressions with Relational Operator
Using Arithmetic Expressions with Logical Operator
Reductions containing nonnumeric types
Remainder Operator Requires Integer Operands
If-Then Type Mismatch
Case Types Mismatch
If Condition Not Boolean
Case Expression Not Integer
Narrowing Variable Initialization
Variable Initialization Mismatch
Undeclared Variable
Duplicate Variable
Narrowing Function Return
This project requires modification to the bison input file, so that it defines the additional
semantic checks necessary to produce these errors and addition of functions to the library of type
checking functions already provided in types.cc. You must also make some modifications to
the functions provided. You need to add a check to the checkAssignment function for
mismatched types in the case that Boolean and numeric types are mixed. You need to also add
code to the checkArithmetic function to coerce integers to reals when the types are mixed and
the error message must be modified to indicate that numeric rather than only integer types are
permitted.
The provided code includes a template class Symbols that defines the symbol table. It already
includes a check for undeclared identifiers. You need to add a check for duplicate identifiers.
Like the lexical and syntax errors, the compiler should display the semantic errors in the
compilation listing, after the line in which they occur. An example of compilation listing output
containing semantic errors is shown below:
1 — Test of Multiple Semantic Errors
2
3 function test a: integer returns integer;
4 b: integer is
5 if a + 5 then
6 2;
7 else
8 5;
9 endif;
Semantic Error, If Expression Must Be Boolean
10 c: real is 9.8 – 2 + 8;
11 d: boolean is 7 = f;
Semantic Error, Undeclared f
12 begin
13 case b is
14 when 1 => 4.5 + c;
15 when 2 => b;
Semantic Error, Case Types Mismatch
16 others => c;
17 endcase;
18 end;
Lexical Errors 0
Syntax Errors 0
Semantic Errors 3
You are to submit two file
7 attachmentsSlide 1 of 7attachment_1attachment_1attachment_2attachment_2attachment_3attachment_3attachment_4attachment_4attachment_5attachment_5attachment_6attachment_6attachment_7attachment_7
Unformatted Attachment Preview
Here is the approach I recommend for project 3.
1) Study the skeleton project provided, built it and run it so that you understand how semantic
actions are used to perform the evaluation needed to interpret programs in our language.
2) You should incorporate the new features that are in the skeleton into your version of project 2
and be sure that it builds and runs just as the skeleton did. Then confirm that test cases
test1.txt – test4.txt that were provided as test cases for the skeleton code produce the
correct output. Note that changes are required to both parser.y and scanner.l.
3) Make additions as defined by the specification incrementally. Start with adding the literals of
the real and Boolean data types. These changes involve modifications to scanner.l. . Once you
have made these modifications use test5.txt and test6.txt to test them. Shown below is the
output that should result when using both test cases as input:
$ ./compile < test5.txt
1
2
3
4
5
6
-- Function with arithmetic expression using real literals
function main returns real;
begin
8.3e+2 + 2.E-1 * (4.3E2 + 2.8) * 3.;
end;
Compiled Successfully
Result = 1089.68
$ ./compile < test6.txt
1
2
3
4
5
6
7
// Function containing Boolean literals
function main returns boolean;
begin
true and false;
end;
Compiled Successfully
Result = 0
4) Next, add the necessary semantic actions for each of the new arithmetic operators. Create
individual test cases to test each new operator. Once you have verified that the operators are
evaluated correctly in those cases, use test7.txt, which will test all of them along with their
precedence. Shown below is the output that should result when using that test case as input:
$ ./compile < test7.txt
1
2
3
// Arithmetic operators
function main returns integer;
4
5
6
begin
9 + 2 - (5 - 1) / 2 rem 3 * 3 ** 1 ** 2;
end;
Compiled Successfully
Result = 5
5). Do the relational operators next. As before it is a good idea to create individual test cases to
test each new operator. Finally the two logical operators or and not testing each with separate
test cases. Once you have added all the new operators use test8.txt to test them. Shown below
is the output that should result when using that test case as input:
$ ./compile < test8.txt
1 -- Relational and logical operators
2
3 function main returns boolean;
4 begin
5
(5 + 3 > 8 or 9 / 3 = 3) or (7 – 9 < 1) and (not (3 /= 1 * 7) or 6
= 9);
6 end;
Compiled Successfully
Result = 1
6) The if statement would be a good next step. It can be done in one line using the conditional
expression operator. Use test9.txt to test it. Shown below is the output that should result when
using that test case as input:
$ ./compile < test9.txt
1
2
3
4
5
6
7
8
9
10
-- Conditional expression
function main
begin
if not (5
6 + 9
else
8 - 9
endif;
end;
returns integer;
+ 4 >= 9) then
* 3;
rem 7;
Compiled Successfully
Result = 6
7) Do multiple variable declarations next. Use test10.txt and test11.txt to test that change.
Shown below is the output that should result when using both test cases as input:
$ ./compile < test10.txt
1
2
3
4
5
6
7
8
-- Multiple integer variable initialization
function main returns integer;
b: integer is 5 + 1 - 4;
c: integer is 2 + 3;
begin
b + 1 - c;
end;
Compiled Successfully
Result = -2
$ ./compile < test11.txt
1
2
3
4
5
6
7
8
9
10
11
12
-- Variable initialization with real and Boolean variables
function main returns real;
b: real is 5.3 + 1. - 4 / 2.0E-2;
c: boolean is b > 3.e2 and true or false;
begin
if c then
b * 6.4 + 1.5;
else
2.e+3;
endif;
end;
Compiled Successfully
Result = 2000
8) Next make the changes necessary for programs that contain parameters. The parameters are in
the command line arguments, argv. The prototoype of main is:
int main(int argc, char *argv[])
Declare a global array, which is dynamically allocated based on argc, at the top of parser.y. In
main convert each command line argument to a double and store it into that global array. The
function atof will do the conversion of a char* to a double. In the semantic action for the
parameter production, retrieve the value of the corresponding parameter from the global array
and store its value in the symbol table.
Use test12.txt and test13.txt to test that change. Shown below is the output that should
result when using both test cases as input:
$ ./compile < test12.txt 3.6
1
2
3
4
5
-- Single parameter declaration
function main a: real returns real;
begin
a + 1.5;
6
end;
Compiled Successfully
Result = 5.1
$ ./compile < test13.txt 1 8.3
1
2
3
4
5
6
7
8
9
10
-- Two parameter declarations
function main a: boolean, b: real returns real;
begin
if a then
b + 1;
else
b - 1;
endif;
end;
Compiled Successfully
Result = 9.3
9) Save the case statement for last. It is the most challenging. The approach that I recommend is
using an inherited attribute. Study how an inherited attribute is used in the skeleton for the
reductions. A similar approach can be used with the case statement.
Here is pseudo-code for semantic actions for handling the case statement. It uses the sentinel
NAN, not-a-number as the attribute carried up the parse tree to indicate a match has not yet been
found. In that way, the decision can be made at the top level when the value of the case should be
what is in the OTHERS clause:
statement:
CASE expression IS cases OTHERS ARROW statement_ ENDCASE
{If the attribute of cases, is a number then
return it as the attribute otherwise return the
attribute of the OTHERS clause};
cases:
cases case
{if the attribute of cases is a number then return it as the
attribute otherwise return the attribute of case} |
%empty
{Set the attribute to the sentinel NAN} ;
case:
WHEN INT_LITERAL ARROW statement_
{$-2 contains the value of the expression after CASE.
It must be compared with the attribute of INT_LITERAL.
If they match the attribute of this production
should become the attribute of statement_
If they don't match, the attribute should be set to the
sentinel value NAN} ;
NAN
is a constant defined in cmath that represents not-a-number. The function isnan checks
whether a double is NAN.
Use test14.txt to test the case statement. . Shown below is the output that should result when
using that test case as input:
$ ./compile < test14.txt
1
2
3
4
5
6
7
8
9
10
11
// Case selection
function main returns integer;
a: integer is 4 + 2;
begin
case a is
when 1 => 3;
when 2 => (3 + 5 – 5 – 4) * 2;
others => 4;
endcase;
end;
Compiled Successfully
Result = 4
10) The final two test cases, test15.txt and test.16.txt, involve nested statements and
provide a further test of both the if and case statements. Shown below is the output that should
result when using both test cases as input:
$ ./compile < test15.txt 1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
-- Nested if
function main a: integer returns integer;
b: integer is 8;
begin
if a >= 0 then
if b > 5 then
a * 2;
else
a + 5;
endif;
else
a / 2;
endif;
end;
Compiled Successfully
Result = 2
$ ./compile < test16.txt 3 1
1
2
-- Nested case
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function main a: integer, b: integer returns integer;
c: integer is 8;
begin
case a is
when 1 => a * c;
when 2 => a + 5;
when 3 =>
case b is
when 1 => 2;
others => 19;
endcase;
when 4 => a / 2;
others => a + 4;
endcase;
end;
Compiled Successfully
Result = 2
All of the test cases discussed above are included in the attached .zip file.
You are certainly encouraged to create any other test cases that you wish to incorporate in your
test plan. Keep in mind that your compiler should produce the correct output for all syntactically
correct programs, so I recommend that you choose some different test cases as a part of your test
plan. I may use a comparable but different set of test cases when I test your projects.
CMSC 430 Project 3
The third project involves modifying the attached interpreter so that it interprets programs for the
complete language.
You may convert all values to double values, although you can maintain their individual types if
you wish.
When the program is run on the command line, the parameters to the function should be supplied
as command line arguments. For example, for the following function header of a program in the
file text.txt:
function main a: integer, b: integer returns integer;
One would execute the program as follows:
$ ./compile < test.txt 2 4
In this case, the parameter a would be initialized to 2 and the parameter b to 4.
An example of a program execution is shown below:
$ ./compile < test.txt 2 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function main a: integer, b: integer returns integer;
c: integer is
if a > b then
a rem b;
else
a ** 2;
endif;
begin
case a is
when 1 => c;
when 2 => (a + b / 2 – 4) * 3;
others => 4;
endcase;
end;
Compiled Successfully
Result = 0
After the compilation listing is output, the value of the expression which comprises the body of
the function should be displayed as shown above.
The existing code evaluates some of the arithmetic, relational and logical operators together with
the reduction statement and integer literals only. You are to add the necessary code to include all
of the following:
Real and Boolean literals
All additional arithmetic operators
All additional relational and logical operators
Both if and case statements
Functions with multiple variables
Functions with parameters
This project requires modification to the bison input file, so that it defines the additional the
necessary computations for the above added features. You will need to add functions to the
library of evaluation functions already provided in values.cc. You must also make some
modifications to the functions already provided.
You are to submit two files.
1. The first is a .zip file that contains all the source code for the project. The .zip file
should contain the flex input file, which should be a .l file, the bison file, which should
be a .y file, all .cc and .h files and a makefile that builds the project.
2. The second is a Word document (PDF or RTF is also acceptable) that contains the
documentation for the project, which should include the following:
a. A discussion of how you approached the project
b. A test plan that includes test cases that you have created indicating what aspects
of the program each one is testing and a screen shot of your compiler run on that
test case
c. A discussion of lessons learned from the project and any improvements that could
be made
Grading Rubric
Criteria
Functionality
Meets
Does Not Meet
70 points
0 points
Functions with real and Boolean literals
evaluated correctly (5)
Functions with real and Boolean literals
not evaluated correctly (0)
Subtraction and division operators
evaluated correctly (5)
Subtraction and division operators not
evaluated correctly (0)
Remainder operator evaluated
correctly (5)
Remainder operator not evaluated
correctly (0)
Exponentiation operator evaluated
correctly (5)
Exponentiation operator not evaluated
correctly (0)
Additional relational operators
evaluated correctly (5)
Additional relational operators not
evaluated correctly (0)
Additional logical operators evaluated
correctly (5)
Additional logical operators not
evaluated correctly (0)
if conditional expressions evaluated
correctly (10)
if conditional expressions not
evaluated correctly (0)
case conditional expressions evaluated
correctly (10)
case conditional expressions not
evaluated correctly (0)
Functions with multiple variables
evaluated correctly (10)
Functions with multiple variables not
evaluated correctly (0)
Functions with parameters evaluated
correctly (10)
Functions with parameters not
evaluated correctly (0)
15 points
Test Cases
Includes test cases that test real and
Boolean literals (3)
Does not Include test cases that test
real and Boolean literals (3)
Includes test cases that test all
arithmetic operators (3)
Does not include test cases that test all
arithmetic operators (0)
Includes test cases that test all
relational and logical operators (3)
Does not include test cases that test all
relational and logical operators (0)
Includes test cases that test both
conditional expressions (3)
Does not include test cases that test
both conditional expressions (0)
Includes test cases with variables and
parameters (3)
Does not include test cases with
variables and parameters (0)
15 points
Documentation
0 points
Discussion of approach included (5)
Lessons learned included (5)
0 points
Discussion of approach not included (0)
Lessons learned not included (0)
Comment blocks with student name,
project, date and code description
included in each file (5)
Comment blocks with student name,
project, date and code description not
included in each file (0)
CMSC 430 Project 4
The fourth project involves modifying the semantic analyzer for the attached compiler by adding
checks for semantic errors. The static semantic rules of this language are the following:
Variables and parameter names have local scope. The scope rules require that all names be
declared and prohibit duplicate names within the same scope. The type correspondence rules are
as follows:
Boolean expressions cannot be used with arithmetic or relational operators.
Arithmetic expressions cannot be used with logical operators.
Reductions can only contain numeric types.
Only integer operands can be used with the remainder operator.
The two statements in an if statement must match in type. No coercion is performed.
All the statements in a case statement must match in type. No coercion is performed.
The type of the if expression must be Boolean.
The type of the case expression must be Integer
A narrowing variable initialization or function return occurs when a real value is being
forced into integer. Widening is permitted.
Boolean types cannot be mixed with numeric types in variable initializations or function
returns.
Type coercion from an integer to a real type is performed within arithmetic expressions.
You must make the following semantic checks. Those highlighted in yellow are already
performed by the code that you have been provided, although you are must make minor
modifications to account for the addition of real types and the need to perform type coercion and
to handle the additional arithmetic and logical operators.
Using Boolean Expressions with Arithmetic Operator
Using Boolean Expressions with Relational Operator
Using Arithmetic Expressions with Logical Operator
Reductions containing nonnumeric types
Remainder Operator Requires Integer Operands
If-Then Type Mismatch
Case Types Mismatch
If Condition Not Boolean
Case Expression Not Integer
Narrowing Variable Initialization
Variable Initialization Mismatch
Undeclared Variable
Duplicate Variable
Narrowing Function Return
This project requires modification to the bison input file, so that it defines the additional
semantic checks necessary to produce these errors and addition of functions to the library of type
checking functions already provided in types.cc. You must also make some modifications to
the functions provided. You need to add a check to the checkAssignment function for
mismatched types in the case that Boolean and numeric types are mixed. You need to also add
code to the checkArithmetic function to coerce integers to reals when the types are mixed and
the error message must be modified to indicate that numeric rather than only integer types are
permitted.
The provided code includes a template class Symbols that defines the symbol table. It already
includes a check for undeclared identifiers. You need to add a check for duplicate identifiers.
Like the lexical and syntax errors, the compiler should display the semantic errors in the
compilation listing, after the line in which they occur. An example of compilation listing output
containing semantic errors is shown below:
1 — Test of Multiple Semantic Errors
2
3 function test a: integer returns integer;
4
b: integer is
5
if a + 5 then
6
2;
7
else
8
5;
9
endif;
Semantic Error, If Expression Must Be Boolean
10
c: real is 9.8 – 2 + 8;
11
d: boolean is 7 = f;
Semantic Error, Undeclared f
12 begin
13
case b is
14
when 1 => 4.5 + c;
15
when 2 => b;
Semantic Error, Case Types Mismatch
16
others => c;
17
endcase;
18 end;
Lexical Errors 0
Syntax Errors 0
Semantic Errors 3
You are to submit two files.
1. The first is a .zip file that contains all the source code for the project. The .zip file
should contain the flex input file, which should be a .l file, the bison file, which should
be a .y file, all .cc and .h files and a makefile that builds the project.
2. The second is a Word document (PDF or RTF is also acceptable) that contains the
documentation for the project, which should include the following:
a. A discussion of how you approached the project
b. A test plan that includes test cases that you have created indicating what aspects
of the program each one is testing and a screen shot of your compiler run on that
test case
c. A discussion of lessons learned from the project and any improvements that could
be made
Grading Rubric
Criteria
Functionality
Meets
Does Not Meet
70 points
0 points
Generates semantic error when a
remainder operator has non-integer
operands (10)
Does not generate semantic error
when a remainder operator has noninteger operands (0)
Generates semantic error when if and
then types don’t match (10)
Does not generate semantic error
when if and then types don’t match (0)
Generates semantic error when case
types don’t match (10)
Does not generate semantic error
when case types don’t match (0)
Generates semantic error when if
condition is not Boolean (10)
Does not generates semantic error
when if condition is not Boolean (0)
Generates semantic error when case
expression is not integer (10)
Does not generate semantic error
when case expression is not integer (0)
Generates semantic error on narrowing
initialization (10)
Does not generate semantic error on
narrowing initialization (0)
Generates semantic error for duplicate
variables (10)
Does not generate semantic error for
duplicate variables (0)
15 points
Test Cases
Includes test cases that test all type
checking errors (10)
Does not Include test cases that test all
type checking errors (0)
Includes test cases that test all symbol
table errors (3)
Does not include test cases that test all
symbol table errors (0)
Includes test case with multiple errors
(2)
Does not include test case with
multiple errors (0)
15 points
Documentation
0 points
Discussion of approach included (5)
Lessons learned included (5)
Comment blocks with student name,
project, date and code description
included in each file (5)
0 points
Discussion of approach not included (0)
Lessons learned not included (0)
Comment blocks with student name,
project, date and code description not
included in each file (0)
Purchase answer to see full
attachment
Tags:
arithmetic
Logical Operators
multiple variables
User generated content is uploaded by users for the purposes of learning and should be used following Studypool’s honor code & terms of service.
