COOL compiler-second job-parser (PA3) Implementation

Document directory

• 1. Job Objectives
• 2. References
• 3. Prepare the environment
• 4. Actual Work
• 5. Test parser
• 6. output structure
• 7. handle errors
• 8. Notes
• Practical notes:

Note: The implementation of the COOL compiler is an open class network. The address is https://class.coursera.org/compilers/class/index, which can be used to flip the wall.

You can find the required development environment (Virtual Machine images, etc.) and related information in it. If you are interested, you can learn it together.

And discussion.

 

1. Job Objectives

Implements parser and provides two tools: parser Generator -- Bison and the packet parser of the Operation tree structure. The output of parser is an abstract syntax tree (AST ),

What we need to do is to combine the AST constructed API and then use semantic actions in Bison to build this AST.

2. References

A. syntax structure of Cool language, in The Cool Reference Manual

 

B. How to Use the tree structure package in Tour of Cool Support Code

C. Bison documentation, http://www.gnu.org/software/bison/manual/html_node/index.html#Top

3. Prepare the environment

Copy job Folder:

• Cd to your workspace
• Make-f/usr/class/cs143/assignments/PA3/Makefile

4. Actual Work

Modify cool. y in two parts:

• The Declaration is basically completed, but the following parts still need to be done:

I. add an additional type declaration for the new non-terminator you introduced;

II. The Terminator is basically complete;

III. Priority Declaration needs to be added to operators;

• You need to complete the rule part.

5. Test parser

Make parser

./Myparser-p good. cl // Add-p to view the analysis process

# View the output file cool. output

Use the./checkparser. sh good. cl command to compare your implemented parser with the correct parser.

.

6. output structure

The output is an AST. Your semanic actions should also be constructing an AST, and its root type should be program.

Then, the nodes are constructed step by step.

7. handle errors

An error non-Terminator must be provided. At least two error recovery functions must be provided:

A. If a class definition has a syntax error, but this class ends the definition correctly, and the next class definition is correct,

Parser can skip the wrong class and analyze it again from the next correct class.

B. Similarly, parser can recover from the error in feature and continue to analyze the next feature.

8. Notes

A. Priority Declaration can only be used in expressions.

B. The let syntax is a binary syntax. Pay attention to the shift-reduce conflicts caused by it. You can use the generated priority statement in bison

C. Note that all print statements are commented out...

Practical notes:

1. The cool_tree.aps file is the declaration file for the constructors of each tree node.
2. The cool_tree.cc file includes the implementation code of the functions in the above file, and also includes operations on list nodes.
3. Pay attention to the parameters required by the node constructor. The single_Cases above requires the case type, and the function that actually generates the case type is the branch () function, therefore, the correct method should be single_Cases (branch (id, type, expr ))
4. Each semantic action contains two steps: first, mark the location information, and then construct the AST Tree node.
5. The ID must start with lowercase, And the TYPEID must start with uppercase.
6. Each row may not end with a semicolon. For more information, see the class and feature syntax.
7. When a single row expr appears in the function body, it cannot end with a plus sign. To add extra points, use {} to enclose expr.
8. Correct reflexer and refparser files can be found in/home/compilers/cool/lib/. i686.
9. Usage: reflexer good. cl | refparser
10. The error processing is not as complicated as you think. You only need to add an error statement under the expr branch without action. The corresponding class, feature, and other error processing can also be performed accordingly.
11. Note that the syntax definition must use left recursion for unknown reasons... remember that the [formal, [, formal] *] definition must use left recursion ....
12. Expr_list: expr_list ', 'expr, but not 'expr_list: expr', 'expr_list
13. With regard to error handling, the single use of error is not enough to achieve the recovery effect. The error and other symbols need to be used to form an overall error handling syntax to skip this line.
14. For example, IN the let syntax, you need to add the error IN expr and error 'and 'expr_let_part_2 error processing syntaxes to match the entire error line, ignore it, and process the next line.
15. Another example is that the block syntax requires an error ';' to match the entire row.
16. Let Syntax: let x: int, y: int in x => let x: int in let y: int in x, let syntax should be divided into three parts during construction:
17. Part1: let id: type [<-expr]
18. Part2: [, id: type [<-expr] *
19. Part3: in expr

Code:

All the files mentioned above can be found in my github. In fact, you only need to check the cool. y file. All the changes are centered on this file:

Https://github.com/hanks/Compiler