CSCE 425/825 - Compiler Construction


CSCE 425/825
Course Home Page
Course Description
Calendar
Project Upload
Resources
Project
Java
ANTLR
JVM and ASM
Eclipse and Plugins

Course Announcements

  • Aug. 27 : Course web-site has been updated for 2007. Report problems to the instructor.
  • Sep. 12 : No office hours today since the instructor is home sick.
  • Sep. 13 : Here is the blog entry on parallel parsing of DOM. You should be able to understand the basic idea of slides at this point in the course if you want to flip through them.
  • Sep. 25 : In response to a question by a student regarding milestone 1 I wrote this:

    If you want to test a grammar fragment then use the ANTLRWorks Debugger. It will generate a grammar, execute it on your input and show you the syntax tree generated (as well as allow you to step back and forth during the parse). You need to configure some preferences in ANTLRWorks to get this to work, e.g., java compiler. Note that you can either debug fragments of input programs or entire test cases, by pointing ANTLRWorks at the JUnit test input files. Once you are happy with this debugging phase, then generate the entire parser into the proper directory and it should be ready for JUnit testing.

    Second, you can sometimes see subtle differences between parsing of sub-grammars extracted from a large grammar and the action of that sub-grammar in the context of a larger parse. While I cannot find any documention about the differences in behavior, I now believe that it is due to the processing of EOF. The way that I have been successful in resolving this issue is by always having EOF in the production rule that I use as the start rule. For example, if I only want to parse exp, I will create a new production called expFile as follows: 

    expFile
  : exp EOF
  ;
    I then use expFile rather than exp to avoid the issue. Also, what I did is to override reportError method to store all raised exceptions in a set field, and later on query whether the set is empty or not.

  • Oct. 15 : A new version of milestone 2 has been deployed. It fixes a bug in the JUnit test driver which obscured the fact that the JDT implementation has fixed a bug in it's pretty printing functionality from last year. If you download the new milestone all you need to update are the .ast files and the ExtendedASTParserTest.java file.
  • Oct. 17 : A number of you are using the grammar file deployed with milestone 2. Note that in processing field and array access expressions you should feel free to restructure the grammar if it simplifies your work. Currently the rule is of the form: 
    primaryExp : primaryPrefix (primarySuffix)*
    but there are advantages to explicitly separating the field and array accesses as follows: 
    primaryExp : primaryPrefix (arrayAccess | fieldAccess)*
    since this will allow you to customize the semantic actions to process values of the appropriate JDT types that represent array and field access expressions.
  • Oct. 19 : When exporting your solution to an archive file, you can test that it was done correctly by importing it into your workspace again. Note that you will only be able to perform this import if you rename the project in your workspace, since eclipse will not overwrite a project when importing - in fact it won't even appear that the project is available for import.
  • Nov. 1 : A new version of the .etc files for milestone 3 is available here. This fixes the two files I mentioned in class that have output formats based on an old JDT implementation's traversal order. These will be used to evaluate your solution.