Project02 - NTLang
Due in GitHub by Monday, September 21st at 11:59 PM
Create your repo in the GitHub Classroom Assignment published in your section's Piazza
We will give a working reference implementation of the scanner and parser we have worked on in class.
You will expand that implementation to match the EBNF given below, and provide your own bitwise operations and base conversions.
You will use the techniques we've learned for scanning, parsing, and number manipulation to build an interpreter for a little language with the EBNF grammars given below.
Your interpreter will take an expression , a number base, and a width on the command line, and print its output to stdout like this:
Valid inputs for the number base are -b 2, -b 10 (default if -b not given), and -b 16
Valid inputs for the width are -w 4, -w 8, -w 16, and -w 32 (default if -w not given)
Print unsigned ints with -u (this only has meaning for -b 10)
You will write the scanner and parser yourself, without using C strtok() or scanf() or compiler generators such as lex, yacc, bison, antlr, etc.
You will write the base conversion tools yourself without using C printf("%d", i) or printf("%x", i)
Your scanner will read the expression from the command line and create a data structure of tokens.
The EBNF grammar for the scanner is:
As with lab03, your parser will generate parse tree (AST) which represents the meaning of the tokens generated by the scanner.
The parser adds the following elements to the EBNF grammar:
The bitwise operators do the same thing as their counterparts in C:
>> logical shift right
>- arithmetic shift right
<< logical shift left
~ bitwise not
& bitwise and
| bitwise or
^ bitwise xor
Your interpreter will walk the AST depth-first, evaluating the expressions defined by the nodes, and printing the results.
You may want to store the intermediate results in a C uint32_t (unsigned int), to make conversion to binary or hexadecimal easy. It's possible to use a C character string instead if you prefer, but that may be a little more work.
The width parameter controls how many bits wide the output should be.
Grading will have two components: automated and interactive.
For interactive grading, we will schedule 1:1 meetings with the instructor or TAs using a Google Sheet published in your section's Piazza. You should be prepared to share your screen and answer questions about your design and implementation.
Interactive grading counts for 40% of the project grade, as follows:
10% Question 1 (examples given in lecture)
10% Question 2
10% Question 3
10% Code quality
The code quality rubric is:
-2 for inconsistent spacing or indentation
-2 for inconsistent naming or commenting
-2 for commented-out ("dead") code
-2 for redundant or overly complicated code
-2 for messy repo (build products, .actual files, etc.)
Automated grading counts for 60% of your project grade
We will use the maketest tool to grade correctness of your project. You can run it yourself on your local repository to see how your code scores. Instructions are in the README.
Your project must be generated by a Makefile, and the executable must be called project02
There is an extra credit problem, worth one point. It's possible for the expression to overflow the 32 bits in a uint32_t. You can detect this. Examples of correct output:
pi@raspberrypi:~/project02 $ ./project02 -e "0xffffffff"
pi@raspberrypi:~/project02 $ ./project02 -e "0xffffffff1"
overflows uint32_t: ffffffff1
pi@raspberrypi:~/project02 $ ./project02 -e "0x000000000ffffffff"