Define your token types (syntactic categories/tag set) and develop a lexical analyzer. While the recommended practice is to integrate this module with the parser, it is not obligatory. • Your lexical analyzer (scanner) is expected to perform greedy matching of characters in the input stream. • Characters that do not belong to any token type should be treated as errors. • Whitespace characters serve as stopping points. The analyzer may resume processing from an error state after encountering these characters.
• (2 points) Recognize all integers.
• (2 points) Recognize all real numbers.
• (2 points) Recognize all operators.
• (2 points) Recognize all variables.
• (2 points) Recognize all error tokens (any other special symbols)
Define your syntax using your token types and implement a syntactic analyzer. • The inputs for the parser should be sourced from the lexical analyzer. You are permitted to adjust your lexical analyzer from the previous phase to meet the requirements of this phase. • Each line in the output file should represent either the bracketing result of the parser or an error. • The result from the parser forms a parse tree, with all tokens enclosed in the same brackets sharing a common parent node. • Establish a symbol table for identifiers. Each entry in the symbol table should include at least:– Lexeme– Line number (latest definition)– Starting position– Length– Type(your token type, latest definition)– Value (latest assignment) • Record the details of each lexeme in the symbol table. • You may freely design your error-printing format. • The position of the character in the source file should start from 1.
• (2 points) Correct grammar/result.
• (2 points) Working parser.
• (2 points) Use the input token sequence from the lexical analyzer module.
• (2 points) Symbol table.
• (2 points) Identify every error with its line number and position in the line.
Convert each line of expression or statement into assembly codes • The generated codes should constitute the output from all three phases: lexical analysis, syntactic analysis, and code generation. You are allowed to modify codes from previous phases to meet the requirements of this phase. • The generated codes for each input line are separated by a blank line. • For an invalid input line, only print “ERROR”. • If the statement is an expression, store the result value to the @print address in the memory. • In the case of a boolean expression:– If the result is true, load @print with the integer constant 1.– Otherwise, load @print with the integer constant 0. • Amemory location of a list address is base + offset * size • All data types require 4 bytes (32 bits) • Optimization of the generated code is not required.
Each assembly instruction has the following structures: OPCODE TARGET SRC1 SRC2 LD R #Im LD R1 R2 LD R @Add ST @Add R
Integer operations. All data are integers. ADD.i R1 R2 R3 SUB.i R1 R2 R3 MUL.i R1 R2 R3 DIV.i R1 R2 R3 EXP.i R1 R2 R3
Floating-point operations. All data are floats. ADD.f R1 R2 R3 SUB.f R1 R2 R3 MUL.f R1 R2 R3 DIV.f R1 R2 R3 EXP.f R1 R2 R3
Comparisons. R2 and R3 store floats. R1 stores an integer. LT.f R1 R2 R3 LE.f R1 R2 R3 GT.f R1 R2 R3 GE.f R1 R2 R3 EQ.f R1 R2 R3 NE.f R1 R2 R3
Conversion FL.i R1 R2 INT.f R1 R2
• (6 points) Appropriate translation scheme
• (2 points) Correct translation for each operator
• (2 points) Tracking of known/declared variables, i.e., use a simple symbol table