shithub: mc

--- a/doc/compiler.txt

+++ b/doc/compiler.txt

@@ -52,13 +52,13 @@

     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,

-    which currenty does nothing other than simply folding trees. In the final

+    which currently 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

-        flatten         Rewrite the complex nodes into simpe ones

+        flatten         Rewrite the complex nodes into simple ones

         opt             Optimize the flattened source trees

         gen             Generate the assembly code

@@ -126,7 +126,7 @@

         'parse/gram.h'. The lexer and parser code is the only code that

         depends on these token constants.

-        The lexer is initalized through 'tokinit(char *file)'. This function

+        The lexer is initialized through 'tokinit(char *file)'. This function

         will open the file passed in, read all the data from it in one go

         and set up the internal data for the tokenizer. The tokenizing is then

         done while the whole file is in memory, which means that this code

@@ -177,7 +177,7 @@

         'checkns()' function. Second, because we need to know the LHS of a

         member expression before we can check if the RHS is valid, and we

         are not guaranteed to know this at the first time that we see it, the

-        expression is assumed to be valid, and this asumption is verified in

+        expression is assumed to be valid, and this assumption is verified in

         a post-processing pass. Casts are validated in a deferred manner

         similarly.

@@ -225,7 +225,7 @@

         deserialized meaningfully.

         The format for this is only documented in the source, and is a

-        straighforward dump of the trees to memory. It is constantly shifting,

+        straightforward dump of the trees to memory. It is constantly shifting,

         and will not reliably work between compiler versions.

     2.6. Usefiles:

@@ -314,7 +314,7 @@

     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

+        Register 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,

--- a/doc/lang.txt

+++ b/doc/lang.txt

@@ -82,8 +82,8 @@

     These are fully described in section 3.2 of this manual.

     In the compiler, single semicolons (';') and newline (\x10)

-    characters are treated identically, and are therefore interchangable.

-    They will both be referred to "endline"s thoughout this manual.

+    characters are treated identically, and are therefore interchangeable.

+    They will both be referred to "endline"s throughout this manual.

 3. SYNTAX OVERVIEW:

@@ -104,7 +104,7 @@

             var:        Declares a variable value. This value may be

                         assigned to, copied from, and modified.

             generic:    Declares a specializable value. This value

-                        has the same restricitions as a const, but

+                        has the same restrictions as a const, but

                         taking its address is not defined. The type

                         parameters for a generic must be explicitly

                         named in the declaration in order for their

@@ -260,7 +260,7 @@

         Blocks are the "carriers of code" in Myrddin programs. They consist

         of series of expressions, typically ending with a ';;', although the

         function-level block ends at the function's '}', and in if

-        statemments, an 'elif' may terminate a block. They can contain any

+        statements, an 'elif' may terminate a block. They can contain any

         number of declarations, expressions, control constructs, and empty

         lines. Every control statement example below will (and, in fact,

         must) have a block attached to the control statement.

@@ -545,7 +545,7 @@

                 current contents, and a type to hold. They are declared by

                 placing the keyword 'union' before a list of tag-type pairs.

                 They may also omit the type, in which case, the tag is

-                suficient to determine which option was selected.

+                sufficient to determine which option was selected.

                     [int, int, char]            a tuple of 2 ints and a char

@@ -694,7 +694,7 @@

         The quoted form searches the local directory for "localpkg".  By

         convention, the package it imports does not match the name

         "localpkg", but instead is used as partial of the definition of the

-        importer's package. This is a confusing description.

+        importers package. This is a confusing description.

         A typical use of a quoted import is to allow splitting one package

         into multiple files. In order to support this behavior, if a package

@@ -783,7 +783,7 @@

         possible, and it is not well served by overly abstract or bulky code.

         The code written should be a readable description of an algorithm,

         aimed at conveying the essential operations in a linear and

-        straightforward fasion.

+        straightforward fashion.

         Write for humans, not machines. Write linearly, so that an algorithm

         can be understood with minimal function-chasing.