Semantic Analyzer Project: Symbol Table & Static Semantic Checking in COP5621, Study Guides, Projects, Research of Computer Science

Download Semantic Analyzer Project: Symbol Table & Static Semantic Checking in COP5621 and more Study Guides, Projects, Research Computer Science in PDF only on Docsity! COP5621 Project Phase 3 Semantic Analyzer Purpose: This project is intended to give you experience in symbol table manipulation and semantic error detec- tion as well as bring together various issues of semantic analysis discussed in class. Project Summary: Your task is to write a static semantic analyzer that creates a symbol table for the source program, augments the abstract syntax tree (produced by the parser) with appropriate semantic information, checks that the source program abides by some of the semantic rules of the PASC language, and reports any violations. Scoping rules: The scope of a name is the region of the program in which the name can be used. For objects de- clared within a procedure and formal parameter names of a procedure, the scope is from the point of declaration to the end of the procedure in which the name is declared, and objects of the same name in other procedures or declared in the main program’s declarations are unrelated. Variables, symbolic constants and procedures declared in the main program are said to be global, accessible from the point of declaration to the end of the program, including the main program body as well as the bodies of procedure that do not redeclare the same name. The scope of the field identifiers of a record is the record type itself and as such they need not be distinct from identifiers declared outside the record type. Procedures can call procedures declared earlier in the program, and a procedure can be either directly or indirectly recursive, by using the forward declaration. The lifetime of object declarations within a procedure is limited to the execution of the procedure (i.e. the values are discarded upon exit), while objects declared as global last until the end of program execution. Static Semantics: The following static semantics must be performed. • All names declared within the same block (i.e., main program, procedure, or record) must be unique. • All names used within the program must be declared such that using the scoping rules, there exists a corresponding declaration visible from each use of a name (i.e., there should be no uses of undeclared names). • The number of array indices in an indexed component should match the number of dimensions declared for that array. • A name declared as a symbolic constant must not be assigned a new value. • Identifier(s) in a subrange (used as array bounds or subrange type definition) must be previously defined as integer constants. 1 Symbol Table Creation: Both static semantic checking and code generation require semantic information about names defined by the user. The symbol table is a data structure that stores the semantic information for each name declaration. A new entry is added to the symbol table as each declaration is encountered during semantic processing. Since code will be generated in a separate phase (in this project) using the information stored in the symbol table (and possibly adding more information to the table), symbol table entries are never removed after being created. If a given name X is defined in two different places in a program (say, as a global constant and then as a local variable within a procedure), then the final symbol table will contain 2 separate entries for X with the appropriate semantic information. Semantic attributes are added to the entry for a particular name at various times. Every entry has NameAttr and TypeAttr attributes which are entered in response to the name’s declaration and contain the unique index into the string table and (a pointer to) the appropriate type tree, respectively. Each entry also has a boolean attribute PreDefinedAttr which is true iff the name represents one of the predefined identifiers of the PASC language. Since PASC has no input/output defined as part of the language itself, the input/output routines are accessible to all PASC programs as a library. The identifiers are predefined by the PASC language as described by the following table. The symbol table should be initialized with an entry for each of these identifiers, where each entry for a routine contains TypeAttr set to point to a procedure (ProceOp) or function (FuncOp) declaration tree with appropriate formal arguments and result type and PreDefineAttr set equal to true. All other entries in the symbol table will have PreDefineAttr set to false. Identifier Description integer The predefined integer type. char The predefined character type. string The predefined string type. Implemented as an array of 256 (0..255) chars. TypeAttr must point to the corresponding ArrayType tree. write May have 1 to n arguments. Print arguments of integer, char or string type and a <return>. read May have 1 to n arguments. Read integers and characters for the given actual arguments and then skip all the characters in the current line, until a <return> is read. chr(i:integer) : char Return the character of ASCII code i. ord(ch: char) : integer Return the ASCII code of character ch. Table 1: Predefined Identifiers in PASC Read(Write) is represented by a ProceOp subtree for its forward declaration. The specs subtree is null for these two procedures since the number and the types of their arguments are not fixed. Chr and ord should be represented by normal forward function declaration trees. Each entry in the symbol table should have a LevelAttr which is entered in response to the name’s declaration and is an integer indicating the level that the symbol was defined (nesting level). Predefined entries should have the smallest nesting level. In order to distinguish between symbolic constants and variables (since they cannot be distinguished by TypeAttr, a boolean IsConstAttr attribute could be attached to all entries. Similarly, you may want a boolean IsFormalAttr attribute to distinguish between formal arguments and local variables. From the description of some of the attributes, it is clear that an attribute could have a value of integer, 2 that id. This may also require minor modifications to your tree manipulation routines of the second phase of this project to handle STNodes. Function calls which were handled as variable accesses (or variable accesses which were handled as function calls) must be converted from variable-access tree to function call tree (or vice verse). These tree structure modifications can be done as the types of the id’s become apparent when replacing IDNode’s by STNodes. Static Semantic Checking Uniqueness of id declarations can be checked when adding new entries to the symbol table for each constant, variable, or procedure declaration. Undeclared id’s can be found when modifying the IDNodes in statement subtrees (and subrange type subtrees) to point to the symbol table. When an undeclared id is encountered, it should be entered into the symbol table to prevent repeat error messages. Procedure calls with the incorrect number or type of arguments and nonvariable arguments passed as call by reference parameters can be checked when augmenting the procedure name’s IDNode leaf in the call with a pointer to the symbol table. Similarly, and incorrect number of indices in an indexed component can be detected when processing the array name’s IDNode in the indexed component. Assigned symbolic constants can be detected by keeping an AssignAttr in each symbol table entry for a symbolic constant, initially set to false and subsequently set to true upon replacing the left operand’s IDNode in an assignment subtree. Immediately after processing the statement subtree for that block, the current block’s symbol table entries are scanned, emitting a warning for each AssignAttr equal to true. Type checking is not required in this assignment. Testing the semantic Analyzer: Your semantic analyzer should output the complete symbol table and the augmented syntax tree. For grading ease, your syntax tree print routine should adhere to the same specifications as the sec- ond project with the following modification. Since each IDNode has been replaced by an STNode, [ID:tokenvalue, lexeme] should be replaced by [STID: symbol table index, lexeme]. You will need to change the tree print routine to handle this. You might also have to change the symbol table printer that is provided. The changed format should be a clear, concise format including all attributes of every entry. All the attributes should be clearly defined. Error Handling: Your semantic analyzer should print descriptive error messages and recover from all detected static semantic errors to find any additional semantic errors. Error messages should be as descriptive as possible, given the available information at the time of error detection. Assignment Submission and Deadline: The due date for this project is March 28 when you must hand-in your programs and do a demo. Grading policy: • Recognize correct programs (20) • Correctly perfrom the six required semantic checks (5x6). • Generate correct enhanced abstract syntax tree (20) 5 • Generate correct symbol tables (20) • Error reporting (10). 6