In this phase we will try to debug the compiler in order to allow the compiler to compile itself.
The idea is to take one file from the compiler source and try to compile it with the compiler itself. If that is successful, then assemble the output and link with the rest of the compiler compiled with the standard compiler. Then test the resulting compiler. Before deciding that the produced compiler is correct be sure it passes the validation tests. If so, then use the produced compiler to compile the source file and see if the second produced compiler will also pass the validation tests. If this also works, then repeat the process one more time.
Problems can therefore occur at several levels:
You should keep a log of your work. This log should be written in a simple ASCII text file named "LOG". (Please, no Microsoft Word files, or PDF files, or Postscript files.) Each time you sit down to work please record the date and how long you worked. Also summarize what steps you took, what you learned, and what you accomplished during the session. If you fix bugs, then be sure to indicate which files were patched and what the edits were.
Your submission should include your LOG file as well as any patched files and the test files that isolated the bugs. The test files are important because they will be added to the validation tests. Remember that the identification of a bug is important even if you don't come up with a fix.
By "what you learned" I am asking you to provide some information about what compiler source files you looked at when you were investigating a bug. And what information you gathered from looking at the files. Of course, you can also use me as a resource. If you learn anything from me, also cite that in your log.
I will primarily use your log to assign you a grade for this phase. I will be looking for you to exhibit knowledge about how the compiler works as you investigate bugs you encounter. Fixing bugs is not required to get a good grade (although fixing bugs is a good thing!). I realize some bugs are going to be harder than others and what I am really interested in is your overall knowledge of the compiler.
I am looking for you to give me 10-12 hours of work on this assignment. But, please, make these focused and productive hours.
Each student will be given one file to begin work with from a list of files. If you are able to get the file to compile and validate successfully and you still have some hours to expend, then move on to the unassigned files at the end of the list.
acharder: analyze.c clb5: analyzeExpr.c djbriere: analyzeStmt.c dtv: astmem.c fx: bucket.c jdd2: constExpr.c jgootee: decl2.c jjnatale: decl.c joshc: encodeExpr.c mrengan: encodeStmt.c rafoulks: main.c relong: regAlloc.c : semUtils.c : symtab.c : tree.c : types.c : utils.c
The first step in compiling a file is to preprocess it. This must be done on turing.unh.edu using cpp. It is probably best to use the -P flag so that cpp does not generate #line directives, although actually pcc3 can handle those.
The phase6 release of the pcc3 source files will be available in ~cs712/public/phase5 on Monday May 5. You can begin your work on phase 6 by using your compiler from phase 5 and a pre-release of the phase6 code that will be available Monday April 28.
To turn in this assignment use the ~cs712/bin/submit command with "phase6", passing "LOG" and the other files that you want to turn in. You must be logged into turing.unh.edu when you submit.
Submissions can be checked by typing (also on turing.unh.edu):
~cs712/bin/scheck phase6
To receive full credit for the assignment, you must turn in your files prior to 8am on Thursday May 15. However, the late penalty for code submitted after that time will start at 20 points, and will be increased by 5 points for each additional day. No phase 6 programs may be submitted after 8am on Monday May 19.
Comments and questions should be directed to hatcher@unh.edu