summaryrefslogtreecommitdiff
path: root/doc/compiler.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/compiler.txt')
-rw-r--r--doc/compiler.txt44
1 files changed, 22 insertions, 22 deletions
diff --git a/doc/compiler.txt b/doc/compiler.txt
index 20593ca..e296c0e 100644
--- a/doc/compiler.txt
+++ b/doc/compiler.txt
@@ -48,23 +48,23 @@ TABLE OF CONTENTS:
The compilation is divided into a small number of phases. The first phase
is parsing, where the source code is first tokenized, the abstract syntax
tree (AST) is generated, and semantically checked. The second phase is the
- machine dependent tree flattening. In this phase, the tree is decomposed
+ machine-dependent tree flattening. In this phase, the tree is decomposed
function by function into simple operations that are relatively close to
- the machine. Sizes are fixed, and all loops, if statements, etc are
- replaced with gotos. The next phase is a machine independent optimizer,
+ the machine. Sizes are fixed, and all loops, if statements, etc. are
+ replaced with gotos. The next phase is a machine-independent optimizer,
which currenty does nothing other than simply folding trees. In the final
phase, the instructions are selected and the registers are allocated.
So, to recap, the phases are as follows:
- parse Tokenize, parse and analyze the source.
+ parse Tokenize, parse, and analyze the source
flatten Rewrite the complex nodes into simpe ones
opt Optimize the flattened source trees
gen Generate the assembly code
- 1.1. Tree Structure.
+ 1.1. Tree Structure:
- File nodes (n->type == Nfile) represents the being compiled. The current
+ File nodes (n->type == Nfile) represent the files being compiled. The current
node is held in a global variable called, unsurprisingly, 'file'. The
global symbol table, export table, uses, and other compilation-specific
information is stored in this node. This implies that the compiler can
@@ -113,7 +113,7 @@ TABLE OF CONTENTS:
2.1. Lexing:
- Lexing occurs in parse/tok.c. Because we desire to use this lexer from
+ Lexing occurs in parse/tok.c. Because we want to use this lexer from
within yacc, the entry point to this code is in 'yylex()'. As required
by yacc, 'yylex()' returns an integer defining the token type, and
sets the 'tok' member of yylval to the token that was taken from the
@@ -122,7 +122,7 @@ TABLE OF CONTENTS:
allows yyerror to print the last token that was seen.
The tokens that are allowable are generated by Yacc from the '%token'
- definiitions in parse/gram.y, and are placed into the file
+ definitions in parse/gram.y, and are placed into the file
'parse/gram.h'. The lexer and parser code is the only code that
depends on these token constants.
@@ -142,7 +142,7 @@ TABLE OF CONTENTS:
2.2. AST Creation:
- The parser used is a traditional Yacc based parser. It is generated
+ The parser used is a traditional Yacc-based parser. It is generated
from the source in parse/gram.y. The starting production is 'file',
which fills in a global 'file' tree node. This 'file' tree node must
be initialized before yyparse() is called.
@@ -167,7 +167,7 @@ TABLE OF CONTENTS:
complete as possible, and making sure that the types of globals
actually match up with the exported types.
- The next step is the actual type inference. We do a bottom up walk of
+ The next step is the actual type inference. We do a bottom-up walk of
the tree, unifying types as we go. There are subtleties with the
member operator, however. Because the '.' operator is used for both
member lookups and namespace lookups, before we descend into a node
@@ -203,7 +203,7 @@ TABLE OF CONTENTS:
So, in the 'typesub()' function, we iterate over the entire tree,
replacing every instance of a non-concrete type with the final
mapped type. If a type does not map to a fully concrete type,
- this is where we error.
+ this is where we flag an error.
FIXME: DESCRIBE HOW YOU FIXED GENERICS ONCE YOU FIX GENERICS.
@@ -232,15 +232,15 @@ TABLE OF CONTENTS:
Usefiles are more or less files that consist of a single character tag
that tells us what type of tree to deserialize. Because serialized
- trees are compiler version dependant, so are usefiles.
+ trees are compiler version dependent, so are usefiles.
3. FLATTENING:
- This phase is invoked repeatedly on each top level declaration that we
+ This phase is invoked repeatedly on each top-level declaration that we
want to generate code for. There is a good chance that this flattening
- phase should be made machine independent, and passed as a parameter
+ phase should be made machine-independent, and passed as a parameter
a machine description describing known integer and pointer sizes, among
- other machine attributes. However, for now, it is machine dependent,
+ other machine attributes. However, for now, it is machine-dependent,
and lives in 6/simp.c.
The goal of flattening a tree is to take semantically involved constructs
@@ -277,7 +277,7 @@ TABLE OF CONTENTS:
3.2. Complex Expressions:
Complex expressions such as copying types larger than a single machine
- word, pulling members out of structures, emulated multiplication and
+ word, pulling members out of structures, emulating multiplication and
division for larger integers sizes, and similar operations are reduced
to trees that are expressible in terms of simple machine operations.
@@ -298,7 +298,7 @@ TABLE OF CONTENTS:
4.1. Constant Folding:
Expressions with constant values are simplified algebraically. For
- example, the expression 'x*1' is simplified to simply 'x', '0/n' is
+ example, the expression 'x*1' is simplified to 'x', '0/n' is
simplified to '0', and so on.
@@ -306,18 +306,18 @@ TABLE OF CONTENTS:
5.1. Instruction Selection:
- Instruction selection is done via a simple hand written bottom up pass
+ Instruction selection is done via a simple handwritten bottom-up pass
over the tree. Common patterns such as scaled or offset indexing are
- recognized by the patterns, but no attempts at finding an optimal
- tiling are made.
+ recognized by the patterns, but no attempts are made at finding an
+ optimal tiling.
5.2. Register Allocation:
Register allocation is done via the algorithm described in "Iterated
- Regster Coalescing", by Appel and George. As of the time of this
+ Regster Coalescing" by Appel and George. As of the time of this
writing, the register allocator does not yet implement overlapping
register classes. This will be done as described in "A generalized
- algorithm for graph-coloring register allocation", by Smith, Ramsey,
+ algorithm for graph-coloring register allocation" by Smith, Ramsey,
and Holloway.
6: TUTORIAL: ADDING A STATEMENT: