Skip to content

Commit

Permalink
changed the tabs in the readme to spaces. It was bothering me
Browse files Browse the repository at this point in the history
  • Loading branch information
@amangel
amangel committed Apr 30, 2012
1 parent aa882ac commit f6c0649
Showing 1 changed file with 71 additions and 71 deletions.
142 changes: 71 additions & 71 deletions README
View file
@@ -1,11 +1,11 @@
README File for Flair Compiler

Written by Aaron Mangel
Zach Abbott
Zach Abbott
Zan Preston

Current State of Compiler
>>scanner -- due Friday, February 10
>>parser, step 1 -- due Friday, February 24
>>parser, step 2 -- due Friday, March 9
Expand All @@ -14,74 +14,74 @@ Current State of Compiler
>>code generator, step 2 -- due Friday, April 27

Usage:
javac driver.java --To compile
java driver path/to/filename --To execute where path/to/filename is path
javac driver.java --To compile
java driver path/to/filename --To execute where path/to/filename is path
to your Flair Program

Alternately, running either the runAllValidPrograms.sh or runInvalidPrograms.sh
will compile the program on the first run, and will execute all other specified
programs on each future run.
Alternately, running either the runAllValidPrograms.sh or runInvalidPrograms.sh
will compile the program on the first run, and will execute all other specified
programs on each future run.

SCANNER
The primary class for the scanner is CompilerStateScanner. It scans its input
on a by-character basis. It begins in a start state, and then determines if
the following character is a valid state transition while also determining
the type of token being created. Once an invalid state transition is
detected, it breaks off what it has so far and attempts to make a valid
token out of it (i.e. check if it is a valid integer, identifier, etc.).
The primary class for the scanner is CompilerStateScanner. It scans its input
on a by-character basis. It begins in a start state, and then determines if
the following character is a valid state transition while also determining
the type of token being created. Once an invalid state transition is
detected, it breaks off what it has so far and attempts to make a valid
token out of it (i.e. check if it is a valid integer, identifier, etc.).

LexicalException is thrown for an illegal token detected in the input
Flair Program. When an exception is caught, an error message will be output
to standard out, anything that was being read in at the time will be dropped
and the scanner will attempt to continue reading until it reaches the end of
the specified input file.
LexicalException is thrown for an illegal token detected in the input
Flair Program. When an exception is caught, an error message will be output
to standard out, anything that was being read in at the time will be dropped
and the scanner will attempt to continue reading until it reaches the end of
the specified input file.

PARSER
The primary class for the scanner is the CompilerParser. It reads the token
stream that was generated by the scanner, considering each token against the
parsing stack and a table which was built from the FIRST/FOLLOW sets for the
Flair grammar.
The file parseTable.dat must be located in the same directory as the compiled
driver.class. Without this file, the parser table cannot be populated and
the parsing portion of the program will throw an exception and quit.
The table used for the parsing is sparsely populated. Cells which correspond
to an invalid combination are not filled. The table will be filled by loading
a local file, parsingTable.dat, which should not be modified.
ParsingException is thrown if the stream of tokens is different than what is
expected by the grammar. When the exception is thrown, the program will
display an error and close.
The second portion of the parser is the creation of the Semantic stack of
nodes from the parsed program. The nodes are created as the expressions
are identified from the parsed program. Ultimately, every program has a
program node at the top, with a set of declarations, followed by the body
of the program.
The primary class for the scanner is the CompilerParser. It reads the token
stream that was generated by the scanner, considering each token against the
parsing stack and a table which was built from the FIRST/FOLLOW sets for the
Flair grammar.
The file parseTable.dat must be located in the same directory as the compiled
driver.class. Without this file, the parser table cannot be populated and
the parsing portion of the program will throw an exception and quit.
The table used for the parsing is sparsely populated. Cells which correspond
to an invalid combination are not filled. The table will be filled by loading
a local file, parsingTable.dat, which should not be modified.
ParsingException is thrown if the stream of tokens is different than what is
expected by the grammar. When the exception is thrown, the program will
display an error and close.
The second portion of the parser is the creation of the Semantic stack of
nodes from the parsed program. The nodes are created as the expressions
are identified from the parsed program. Ultimately, every program has a
program node at the top, with a set of declarations, followed by the body
of the program.
SEMANTIC CHECKER
The semantic checker is implemented using the Visitor pattern. It traverses
the node tree that was created by the final step of the parser. Initially, it
creates a symbol table with the variable and function definitions in the
program then continuing to check the types of every statement. Warnings are
displayed if any of several situations are encountered. The SemanticWarnings
attempt to provide as much information as is readily available in the current
design to be able to find the problem.
In running the typechecker, any semantic warnings will be collected and
displayed at the end of a session.
Semantic warnings include:
return statement that is not at the end of a function - unreachable code
return statement in the main program
every function contains a return statement
using a variable before it has been declared
calling a function with in appropriate parameters of the appropriate types
Other issues that were suggested that are taken care of in previous sections
of the compiler include:
user defined print function - this is caught by the parser section
using the print function in an assignment statement - caught by parser
The semantic checker is implemented using the Visitor pattern. It traverses
the node tree that was created by the final step of the parser. Initially, it
creates a symbol table with the variable and function definitions in the
program then continuing to check the types of every statement. Warnings are
displayed if any of several situations are encountered. The SemanticWarnings
attempt to provide as much information as is readily available in the current
design to be able to find the problem.
In running the typechecker, any semantic warnings will be collected and
displayed at the end of a session.
Semantic warnings include:
return statement that is not at the end of a function - unreachable code
return statement in the main program
every function contains a return statement
using a variable before it has been declared
calling a function with in appropriate parameters of the appropriate types
Other issues that were suggested that are taken care of in previous sections
of the compiler include:
user defined print function - this is caught by the parser section
using the print function in an assignment statement - caught by parser

CODE GENERATION
The code generator handles Flair in several steps.
Expand All @@ -100,15 +100,15 @@ CODE GENERATION
in regards to register usage.

We've also decided to allocate the registers as follows:
Register
0 - first register used in all computations
1 - second register used in all computations
2 - register holds the start point to the program frame
3 - register holds the start point of the current stack frame
4 - register holds the size of the current stack frame
5 - register is used for returning values from a function call
6 - register is used to hold 0
7 - register is reserved for the program counter
Register
0 - first register used in all computations
1 - second register used in all computations
2 - register holds the start point to the program frame
3 - register holds the start point of the current stack frame
4 - register holds the size of the current stack frame
5 - register is used for returning values from a function call
6 - register is used to hold 0
7 - register is reserved for the program counter

Testing the program involved incrementally building an increasingly complex
program one type of command at a time. Basic mathematical commands were
Expand Down

0 comments on commit f6c0649

Please sign in to comment.