Rename page and add pop instruction to part 5 of compiler series

content/blog/00_compiler_intro.md

@@ -137,6 +137,6 @@ Here are the posts that I've written so far for this series:
 * [Typechecking]({{< relref "03_compiler_typechecking.md" >}})
 * [Small Improvements]({{< relref "04_compiler_improvements.md" >}})
 * [Execution]({{< relref "05_compiler_execution.md" >}})
-* [Compilation]({{< relref "06_compiler_semantics.md" >}})
+* [Compilation]({{< relref "06_compiler_compilation.md" >}})
 * [Runtime]({{< relref "07_compiler_runtime.md" >}})
 * [LLVM]({{< relref "08_compiler_llvm.md" >}})

content/blog/05_compiler_execution.md

@@ -558,7 +558,9 @@ rule to Unwind:
     {{< /gmachine_inner >}}
 {{< /gmachine >}}
 
-Just one more! Sometimes, it's possible for a tree node to reference itself.
+Just a couple more special-purpose instructions, and we're done!
+
+Sometimes, it's possible for a tree node to reference itself.
 For instance, Haskell defines the
 [fixpoint combinator](https://en.wikipedia.org/wiki/Fixed-point_combinator)
 as follows:
@@ -586,9 +588,27 @@ We can allocate an indirection on the stack, and call Update on it when
 we've constructed a node. While we're constructing the tree, we can
 refer to the indirection when a self-reference is required.
 
+Lastly, we also define a Pop instruction, which just removes
+some number of nodes from the stack. We want this because
+calling Update at the end of a function modifies a node further up the stack,
+leaving anything on top of the stack after that node as scratch work. We get
+rid of that scratch work simply by popping it.
+
+{{< gmachine "Pop" >}}
+    {{< gmachine_inner "Before">}}
+    \( \text{Pop} \; n : i \quad a_1, a_2, ..., a_n : s \quad d \quad h \quad m \)
+    {{< /gmachine_inner >}}
+    {{< gmachine_inner "After" >}}
+    \( i \quad s \quad d \quad h \quad m \)
+    {{< /gmachine_inner >}}
+    {{< gmachine_inner "Description" >}}
+    Pop \(n\) nodes from the stack.
+    {{< /gmachine_inner >}}
+{{< /gmachine >}}
+
 That's it for the instructions. Knowing them, however, doesn't
 tell us what to do with our `ast` structs. We'll need to define
 rules to translate trees into these instructions, and I've already
 alluded to this when we went over `double 326`.
 However, this has already gotten pretty long,
-so we'll do it in the next post: [Part 6 - Compilation]({{< relref "06_compiler_semantics.md" >}}).
+so we'll do it in the next post: [Part 6 - Compilation]({{< relref "06_compiler_compilation.md" >}}).