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 8-10 hours of work on this assignment. But, please, make these focused and productive hours.
Here are the initial file assignments. Each student is given one file to begin work with. 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 next file in the list.
agkeller: analyze.c cdeng: analyzeExpr.c ckraft: analyzeStmt.c cwprint: astmem.c dtv: bucket.c fpei: constExpr.c jfree: decl2.c jldenhup: decl.c kirt: encodeExpr.c mmeara: encodeStmt.c pfw: main.c qtao: regAlloc.c rglr: semUtils.c rpigman: symtab.c rzimrot: tree.c sy: types.c vanim: utils.c yshi: analyze.c
The first step in compiling a file is to preprocess it. This must be done on a CISUNIX Alpha 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 phase5 release of the pcc3 source files will be available in ~cs712/public/phase5 on Monday April 29. You can begin your work on phase 5 by using your compiler from phase 4 and a pre-release of the phase5 code that is available now. This is phase4 code that has been cleaned up for compiling with the phase5 release.
To turn in this assignment use the ~cs712/bin/submit command with "phase5", passing "LOG" and the other files that you want to turn in. You must be logged into a CIS Alpha when you submit.
Submissions can be checked by typing (also on a CIS Alpha):
~cs712/bin/scheck phase5
To receive full credit for the assignment, you must turn in your files prior to 8am on Monday May 13. Late submissions will be accepted at the penalty of 5 points per day up to 8am on Thursday May 16.
Comments and questions should be directed to hatcher@unh.edu