Web-Projects/blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Remove TODOS from part 5 of compiler series

Browse Source
This commit is contained in:
Danila Fedorin 2019-09-04 01:31:31 -07:00
parent 3bce9743e5
commit e3fd13c0c1
1 changed files with 29 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
content/blog/05_compiler_execution.md
View File

@ -272,8 +272,29 @@ the thing we apply it to. We then create a new node on the heap
that is an `NApp` node, with its two children being the nodes we popped off. that is an `NApp` node, with its two children being the nodes we popped off.
Finally, we push it onto the stack. Finally, we push it onto the stack.
Let's try use these instructions to get a feel for it. Let's try use these instructions to get a feel for it. In
{{< todo >}}Add an example, probably without notation.{{< /todo >}} order to conserve space, let's use \\(\\text{G}\\) for PushGlobal,
\\(\\text{I}\\) for PushInt, and \\(\\text{A}\\) for PushApp.
Let's say we want to construct a graph for `double 326`. We'll
use the instructions \\(\\text{I} \; 326\\), \\(\\text{G} \; \\text{double}\\),
and \\(\\text{A}\\). Let's watch these instructions play out:
$$
\\begin{align}
[\\text{I} \; 326, \\text{G} \; \text{double}, \\text{A}] & \\quad s \\quad & d \\quad & h \\quad & m[\\text{double} : a\_d] \\\\\\
[\\text{G} \; \text{double}, \\text{A}] & \\quad a\_1 : s \\quad & d \\quad & h[a\_1 : \\text{NInt} \; 326] \\quad & m[\\text{double} : a\_d] \\\\\\
[\\text{A}] & \\quad a\_d, a\_1 : s \\quad & d \\quad & h[a\_1 : \\text{NInt} \; 326] \\quad & m[\\text{double} : a\_d] \\\\\\
[] & \\quad a\_2 : s \\quad & d \\quad & h[\\substack{\\begin{aligned}a\_1 & : \\text{NInt} \; 326 \\\\ a\_2 & : \\text{NApp} \; a\_d \; a\_1 \\end{aligned}}] \\quad & m[\\text{double} : a\_d] \\\\\\
\\end{align}
$$
How did we come up with these instructions? We'll answer this question with
more generality later, but let's take a look at this particular expression
right now. We know it's an application, so we'll be using MkApp eventually.
We also know that MkApp expects two values on top of the stack from
which to make an application. The node on top has to be the function, and the next
node is the value to be passed into that function. Since a stack is first-in-last-out,
for the function (`double`, in our case) to be on top, we need
to push it last. Thus, we push `double` first, then 326. Finally,
we call MkApp now that the stack is in the right state.
Having defined instructions to __build__ graphs, it's now time Having defined instructions to __build__ graphs, it's now time
to move on to instructions to __reduce__ graphs - after all, to move on to instructions to __reduce__ graphs - after all,
@ -566,6 +587,9 @@ 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 we've constructed a node. While we're constructing the tree, we can
refer to the indirection when a self-reference is required. refer to the indirection when a self-reference is required.
That's it for the instructions. Next up, we have to convert our expression That's it for the instructions. Knowing them, however, doesn't
trees into such instructions. However, this has already gotten pretty long, tell us what to do with our `ast` structs. We'll need to define
so we'll do it in the next post. 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: (link me!)