CSc 453 : Programming Assignment 3 Milestone 1 (Type Checking and Semantic Actions)
Start Date: Mon Feb 15, 2016
Due Date: 11:59 PM, Tue Feb 23 Fri Feb 26, 2016
1. General
This assignment involves augmenting your parser to carry out some
semantic actions, which involve processing declarations and managing
symbol tables; checking type consistency of programs; and constructing
syntax trees. The rules for processing declarations and checking type
consistency are given in the
μC Language Specification.
For this milestone, you need to handle the
nano-C subset of μC.
Your program will silently accept correct inputs, and report error messages
for inputs containing errors.
The exit status of your program should be 0 if no errors are encountered during processing,
and 1 if any errors (including syntax and/or semantic errors) are encountered at any point.
2. What's an error and what is not
The point of this milestone is to help you make progress on type-checking
and semantic actions for μC. It does this by carrying out these actions
for a subset of μC. It is important to note that this is not intended
to create any work that has to be undone when processing all of μC.
Because of this, for this compiler your compiler does not have to
enforce any of the restrictions that are specific to nano-C but not
μC: these restrictions simply specify the subset of the
language you need to implement for this milestone. The test cases for this
milestone will all meet these restrictions.
For example, one of the restrictions that is specific to nano-C but not μC
is that a function has at most one argument. This does not mean that you
have to check and give error messages for functions with more than one argument
(since this would then have to be undone when going to full μC). It means
only that the test cases for this milestone will only contain functions with
at most one argument.
What does and does not count as an error for this milestone:
-
If a program feature is not legal in μC then it is
necessarily also not legal in nano-C and should be reported
as an error.
-
If a program feature is legal in μC but is not part of
nano-C, it is not an error and should not be reported
as an error.
This simply means that this feature will not appear in
any of the test inputs for this milestone.
3. Invoking Your Program
Your program will be called compile. It will read all input from stdin,
and report errors to stderr.
4. Turnin
You should turn in the sources to your code on lectura. These should
include:
-
The sources and headers for your scanner and parser. If you use tools
such as lex, yacc, etc., you should turn in the specifications given to these
tools.
-
A main routine that calls your parser.
-
A make file called Makefile that should support at least the following
targets:
-
compile
The command "make compile" should build
your parser from scratch, by invoking
the appropriate tools (flex, bison, etc.)
on their input specifications, and should result in the creation of an
executable file compile that implements the functionality
specified above for this assignment.
-
clean
The command "make clean" should delete
(at least) all software-generated files in the current directory,
including: C source files created by flex/bison,
e.g., y.tab.h, lex.yy.c, y.output,
etc.; object files, *.o; as well as the executable file
compile.
-
Any additional material you wish to turn in. Any documentation or comments
may be turned in in a file README.
To turn in your files, use the command
turnin cs453s16-assg3ms1
file1
file2
...
filen
Turn in the files you want to submit just as they are: don't zip them up
or turn in a directory containing your files.
For more information on the turnin command, try man turnin.
Note: The turnin command copies the files submitted
into another directory. Because of this, programs that use
relative path names in include files and make files (e.g.,
#include "../../foo/bar/baz.h") may not
compile and execute correctly once they are
turned in. Please avoid using relative pathnames.
The output of your program will be compared with the "expected" output using
diff utility (see diff(1)).
With the exception of error messages, your output must follow
the specification exactly.
For this reason it is recommended that you follow
the specification, and instructions for turnin, closely.