Semantic Actions Two (Part 6 of 7)
Date Assigned: 4/1/15
Date Due: 4/17/15 11:59pm
Points: 50 pts
The following specifications presume the use of pccd13defines.h. DO NOT MODIFY THIS FILE.
Problem: You are to implement the set of Semantic Actions in your Bottom Up parser. You should
produce a runnable quad file that invokes main().
Semantic Actions Two
You are to write the set of Semantic Actions in your Bottom Up parser. These actions are:
•
Quad File generation
◦ You must generate the quads for all the expressions handled in the BU.
◦ You must implement global variables, arrays, and variable initialization.
◦ You must allocate temporary variables.
◦ The BU expression stack is changing form. Each entry on the stack now has additional
attributes: Level, Address. Level and address indicate where the actual value of the dummy
nonterminal may be found. This may refer to a temporary location or a variable's location.
You may add other fields to the expression stack as needed. A field tracking whether or not
the entry can be used as an LValue is recommended.
◦ You must implement the output statement in your top-down parser.
◦ You need to generate the function call to invoke main().
•
Semantic Error Checking
◦ Check to insure that only array-type id's precede [ ]s.
◦ Check to insure that function calls use ids of type FUNCNAME.
◦ Check to insure that all ids have been declared.
Driver
Test your sa2 by constructing a driver that performs the following:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Add all reserved words to the symbol table
Read a file name from the command line and open the file
Look for a command line argument ( --lexdebug) and turn on the Lex debug output.
Look for a command line argument (--tddebugenter) and turn TD debugging to display
when a function is entered.
Look for a command line argument (--tddebugleave) and turn TD debugging to display
when a function is left.
Look for a command line argument (--budumphandle) and turns on the BU debugging
output (except for printing the entire expression but does include the ACCEPT/REJECT line).
Look for a command line argument (--sa1symdump) and dump the symbol table
immediately before each function is exited (as in SA1).
Look for a command line argument (-o quadfile.q) to determine where to write the Quad
File. If this option is missing, write the Quad File to quad.q
Parse the file, outputting the appropriate data.
10.Dump the constant table. The constant table needs to be in sorted order (ascending) based on
the constant value.
11.Dump the runtime stack up to (and including) the next available location. The runtime stack
needs to be in sorted order (ascending) by stack address.
12.Dump the error table. If it's empty, print “0 Errors.”
13.Print the Quad File to the screen.
► All output must go to stdout!
Things you DO NOT handle in SA2:
•
Quad File generation
◦ if, for, input, return
•
Semantic Error Checking
◦ Type checking
Testing
Testing will be based on running your quad file through the interpreter. The output of the interpreter
will be captured and compared with expected output. I will not be diff-ing quad files since there is
quite a bit of variation possible.
Quad Production
You will need to add more quads to the list that you could produce for Semantic Actions One.
Hopefully, you built a forward looking quad generation framework that is flexible enough to build all
the necessary quads. The quads produced by expressions, or subexpressions, should store their result in
either a variable's memory location or a temporary location on the stack. You do not need to (but you
may) reuse stack locations for temporary variables.
Error Handling
All errors must be displayed after the entire program is parsed in an error table. Only the first error on
each line will be displayed. Be sure to provide appropriate context information for each error. Do not
produce a Quad File if any errors are found. If the error table is empty, print “0 Errors.”
Sample input and output:
Input File:
main ()
{
int a;
}
a = 100;
a = a + 1;
output (a);
Output:
0123456789012345678901234567890123456789012345678901234567890123456789012345678
CONSTANT TABLE
CONSTANT VALUE
-------------1
100
RUNTIME STACK ADDRESS
--------------------2
1
RUNTIME STACK
ADDRESS
------0
1
2
3
VALUE
-----1
100
1
-1
0 Errors.
Quad File
--------1 27 0
2 22 0
2 26 2
2 1 4
2 26 4
2 20 4
2 25 0
2 26 0
2 23 0
1 21 0
1 28 0
3
0
100
1
0
2
1
1
2
1
1
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
0
2
0
0
0
0
0
0
0
0
0
3
3
3
0
0
1
0
0
0
0
0
1
2
1
0
0
0
0
1
0
0123456789012345678901234567890123456789012345678901234567890123456789012345678
Subversion/Eclipse
You need to edit the source code in your existing CS480_pcc Eclipse project. Most of the above code
will be contained in the TD and BU modules. Continue to use pcc.c as your driver.
You need to update your Makefile (and Make Targets) to build this driver. The all target must build
the pcc, bu_driver, td_driver, lex_driver and st_driver. Other targets you need to add or update:
run_sa2_valgrind_test1 (use the test case above), clean, and run_sa2_test1 (run the test case above,
printing the output to the console).
WARNING:
This assignment is extremely difficult and there is a large amount of code to write. Do
no put this off until the last weekend. A quality solution here makes SA3 and final
integration [much easier | possible].
Submission
On the day the program is due, turn in a (double-sided, color) copy of the source code (stapled) in this
order:
Makefile
bottom up parser .h/.c
top down parser .h/.c
driver (.h if needed)/.c
any new .h/.c source file combinations
SAVE A TREE: Don't print out any unchanged code not explicitly listed above.
See the syllabus for late policies! 1
Things you may need:
An understanding of addressing modes
Lots of temporary storage locations.
A deep understanding of the Quad file
Patience, planning, and time.
1Be sure to track your hours!
Don't look at anyone else's code!
Douglas J. Ryan / [email protected] © Computer Science Department, Pacific University
Edits by Chadd Williams / [email protected]
Start the interpreter in Trace Mode.
./interpreter file.q -d
(the file name MUST be the first argument, and any second argument starts Trace Mode).
Once in Trace Mode you are prompted with a menu that lets you:
s:
b:
<cr>:
Dump the Stack.
Set a breakpoint at an OpCode type
Single step by pressing [Enter]