Fixed typos up to part 61.

37_Switch/Readme.md

@@ -1,4 +1,4 @@
-# Part 27: Switch Statements
+# Part 37: Switch Statements
 
 In this part of our compiler writing journey, we are going to implement
 the 'switch' statement. This is really tricky for several reasons which
@@ -71,7 +71,7 @@ Otherwise, we let the code branch fall through into the next code branch.
 All of the above is fine and good, except that we have to parse a 'switch'
 statement from top to bottom. This means that we won't know how big the
 jump table should be until after we have parsed all of the cases. This
-also means that, unless perform some clever tricks, we will have generated
+also means that, unless we perform some clever tricks, we will have generated
 the assembly code for all the cases *before* we can generate the jump table.
 
 As you know, I'm writing this compiler following the "KISS principle": keep

41_Local_Var_Init/Readme.md

@@ -141,7 +141,7 @@ and produces the following correct output: `Hello world 17 20`.
 
 ## Conclusion and What's Next
 
-It's nice to have a simple part on this journey now and then,. I'm now starting to
+It's nice to have a simple part on this journey now and then. I'm now starting to
 take wagers with myself as to:
 
  + how many parts to the journey, in total, there will be, and

42_Casting/Readme.md

@@ -382,5 +382,5 @@ reckon with was the issues surrounding `void *`. I feel that I've
 covered most bases here but not all of them, so expect to see
 some `void *` edge cases that I haven't spotted yet.
 
-In the next part of our compiler writing journey, I don't really
-know what I'll do yet.
+In the next part of our compiler writing journey, we'll add some missing
+operators.

44_Fold_Optimisation/Readme.md

@@ -36,8 +36,8 @@ algorithm:
 
   1. Try to fold and replace the left child, i.e. recursively.
   1. Try to fold and replace the right child, i.e. recursively.
-  1. If a binary operation with two literals child leaves, fold that.
-  1. If a unary operation with one literals child leaf, fold that.
+  1. If it's a binary operation with two literals child leaves, fold that.
+  1. If it's a unary operation with one literal child leaf, fold that.
 
 The fact that we replace the sub-trees means we recursively optimise the
 edges of the tree first, then work back up the tree to the root of the

46_Void_Functions/Readme.md

@@ -122,7 +122,7 @@ We modify the code in `param_declaration_list()` as follows:
 ```
 
 Assume that we have scanned in the 'void'. We now `scan(&Peektoken);` to
-see what's up next without altering the current `Token`. If that' a
+see what's up next without altering the current `Token`. If that's a
 right parenthesis, we can leave with `paramcnt` set to zero after skipping
 the 'void' token.
 

48_Static/Readme.md

@@ -158,7 +158,7 @@ void freestaticsyms(void) {
 }
 ```
 
-The overall effect is to treat static declarations as global declaration,
+The overall effect is to treat static declarations as global declarations,
 but to remove them from the symbol table at the end of processing an
 input file.
 

50_Mop_up_pt1/Readme.md

@@ -5,7 +5,7 @@ of our compiler writing journey I don't introduce any major feature.
 Instead, I fix a couple of problems and add a couple of minor
 functions.
 
-## Consecuitve Cases
+## Consecutive Cases
 
 At present, the compiler can't parse
 

51_Arrays_pt2/Readme.md

@@ -4,7 +4,7 @@ In the last part of our compiler writing journey, I realised that I
 had implemented arrays not exactly right. In this part of our compiler
 writing journey, I'll try to rectify things.
 
-To start with, I stepped back and thought a bit about arrays and pointer.
+To start with, I stepped back and thought a bit about arrays and pointers.
 I realised that an array is similar to a pointer except:
 
   1. You can't use the unadorned array identifier as an rvalue.

52_Pointers_pt2/Readme.md

@@ -234,7 +234,7 @@ another struct/union.
 
 So the code is different in that we don't build the leaf AST node for the
 original identifier anymore. We still build AST nodes to add on the offset
-from the base and derefence the pointer to the member.
+from the base and dereference the pointer to the member.
 
 One other difference is this code:
 

54_Reg_Spills/Readme.md

@@ -89,7 +89,7 @@ registers in the reverse order in which we spilled them on the stack.
 Is this something that we can guarantee? In other words, will we ever need
 to reload a register out of order? If so, the stack isn't going to be
 the mechanism that we need. Alternatively, can we write our compiler
-to ensure that the reload in reverse spill order?
+to ensure that the registers reload in reverse spill order?
 
 ## Some Optimisations
 

58_Ptr_Increments/Readme.md

@@ -418,8 +418,7 @@ made from its own source code, I found that we were not propagating
 loop/switch end labels properly.
 
 We've now reached the point where our compiler can parse every one of
-its source code files, generate assembly code for it, and we can link
-them.
+its source code files, generate assembly code for them, and we can link them.
 We have reached the final stage of our journey, one that is probably
 going to be the most painful, the **WDIW** stage: why doesn't it work?
 

59_WDIW_pt1/Readme.md

@@ -17,7 +17,7 @@ the first character at `argv[i]`.
 
 I first thought this was a parsing error, but no. It turned out that
 we were not setting `argv[i]` as an rvalue before we dereferenced it.
-I worked thus out by dumping the AST trees with both `cwj` and `cwj0` and
+I worked this out by dumping the AST trees with both `cwj` and `cwj0` and
 observing the differences between them. What we need to do is mark the expression *after*
 the `*` token as an rvalue. This is now done in `prefix()` in `expr.c`:
 
@@ -217,9 +217,9 @@ compiling itself consistently.
 
 ## Conclusion and What's Next
 
-I didn't think I'd get to the point where I can build `cwj`, `cwj0` and `cwj1` in a
-single step of this journey. I expected we would have a whole pile of bugs
-to fix before we get to this point.
+I didn't think I'd get to the point where I can build `cwj`, `cwj0` and
+`cwj1` in a single step of this journey. I expected we would have a whole
+pile of bugs to fix before we got to this point.
 
 The next problem is to work out why the stage 2 and stage 3 compilers are
 different sizes. Looking at the `size` output, the data and bss sections