summaryrefslogtreecommitdiff
path: root/docs/tutorial/LangImpl5.html
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2007-11-13 07:06:30 +0000
committerChris Lattner <sabre@nondot.org>2007-11-13 07:06:30 +0000
commit41fcea3bdb0b05f16bbb6413370079e0d096578e (patch)
treeb5bf4f143cb5d5fcd02e4029c61b390c3fc9e332 /docs/tutorial/LangImpl5.html
parent0f8d9c04d9feef86cee35cf5fecfb348a6b3de50 (diff)
downloadllvm-41fcea3bdb0b05f16bbb6413370079e0d096578e.tar.gz
llvm-41fcea3bdb0b05f16bbb6413370079e0d096578e.tar.bz2
llvm-41fcea3bdb0b05f16bbb6413370079e0d096578e.tar.xz
Many typos, grammaro, and wording fixes. Patch by
Kelly Wilson, thanks! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44043 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/tutorial/LangImpl5.html')
-rw-r--r--docs/tutorial/LangImpl5.html52
1 files changed, 25 insertions, 27 deletions
diff --git a/docs/tutorial/LangImpl5.html b/docs/tutorial/LangImpl5.html
index 837815a77d..9826844b00 100644
--- a/docs/tutorial/LangImpl5.html
+++ b/docs/tutorial/LangImpl5.html
@@ -55,7 +55,7 @@ User-defined Operators</li>
<p>Welcome to Chapter 5 of the "<a href="index.html">Implementing a language
with LLVM</a>" tutorial. Parts 1-4 described the implementation of the simple
-Kaleidoscope language and included support for generating LLVM IR, following by
+Kaleidoscope language and included support for generating LLVM IR, followed by
optimizations and a JIT compiler. Unfortunately, as presented, Kaleidoscope is
mostly useless: it has no control flow other than call and return. This means
that you can't have conditional branches in the code, significantly limiting its
@@ -71,13 +71,13 @@ have an if/then/else expression plus a simple 'for' loop.</p>
<div class="doc_text">
<p>
-Extending Kaleidoscope to support if/then/else is quite straight-forward. It
+Extending Kaleidoscope to support if/then/else is quite straightforward. It
basically requires adding lexer support for this "new" concept to the lexer,
parser, AST, and LLVM code emitter. This example is nice, because it shows how
easy it is to "grow" a language over time, incrementally extending it as new
ideas are discovered.</p>
-<p>Before we get going on "how" we do this extension, lets talk about what we
+<p>Before we get going on "how" we add this extension, lets talk about "what" we
want. The basic idea is that we want to be able to write this sort of thing:
</p>
@@ -97,7 +97,7 @@ Since we're using a mostly functional form, we'll have it evaluate its
conditional, then return the 'then' or 'else' value based on how the condition
was resolved. This is very similar to the C "?:" expression.</p>
-<p>The semantics of the if/then/else expression is that it first evaluates the
+<p>The semantics of the if/then/else expression is that it evaluates the
condition to a boolean equality value: 0.0 is considered to be false and
everything else is considered to be true.
If the condition is true, the first subexpression is evaluated and returned, if
@@ -105,7 +105,7 @@ the condition is false, the second subexpression is evaluated and returned.
Since Kaleidoscope allows side-effects, this behavior is important to nail down.
</p>
-<p>Now that we know what we want, lets break this down into its constituent
+<p>Now that we know what we "want", lets break this down into its constituent
pieces.</p>
</div>
@@ -118,7 +118,7 @@ If/Then/Else</a></div>
<div class="doc_text">
-<p>The lexer extensions are straight-forward. First we add new enum values
+<p>The lexer extensions are straightforward. First we add new enum values
for the relevant tokens:</p>
<div class="doc_code">
@@ -128,7 +128,7 @@ for the relevant tokens:</p>
</pre>
</div>
-<p>Once we have that, we recognize the new keywords in the lexer, pretty simple
+<p>Once we have that, we recognize the new keywords in the lexer. This is pretty simple
stuff:</p>
<div class="doc_code">
@@ -179,7 +179,7 @@ If/Then/Else</a></div>
<div class="doc_text">
<p>Now that we have the relevant tokens coming from the lexer and we have the
-AST node to build, our parsing logic is relatively straight-forward. First we
+AST node to build, our parsing logic is relatively straightforward. First we
define a new parsing function:</p>
<div class="doc_code">
@@ -296,14 +296,14 @@ height="315"></center>
inserting actual calls into the code and recompiling or by calling these in the
debugger. LLVM has many nice features for visualizing various graphs.</p>
-<p>Coming back to the generated code, it is fairly simple: the entry block
+<p>Getting back to the generated code, it is fairly simple: the entry block
evaluates the conditional expression ("x" in our case here) and compares the
result to 0.0 with the "<tt><a href="../LangRef.html#i_fcmp">fcmp</a> one</tt>"
instruction ('one' is "Ordered and Not Equal"). Based on the result of this
expression, the code jumps to either the "then" or "else" blocks, which contain
the expressions for the true/false cases.</p>
-<p>Once the then/else blocks is finished executing, they both branch back to the
+<p>Once the then/else blocks are finished executing, they both branch back to the
'ifcont' block to execute the code that happens after the if/then/else. In this
case the only thing left to do is to return to the caller of the function. The
question then becomes: how does the code know which expression to return?</p>
@@ -320,25 +320,25 @@ block. In this case, if control comes in from the "then" block, it gets the
value of "calltmp". If control comes from the "else" block, it gets the value
of "calltmp1".</p>
-<p>At this point, you are probably starting to think "oh no! this means my
+<p>At this point, you are probably starting to think "Oh no! This means my
simple and elegant front-end will have to start generating SSA form in order to
use LLVM!". Fortunately, this is not the case, and we strongly advise
<em>not</em> implementing an SSA construction algorithm in your front-end
unless there is an amazingly good reason to do so. In practice, there are two
-sorts of values that float around in code written in your average imperative
+sorts of values that float around in code written for your average imperative
programming language that might need Phi nodes:</p>
<ol>
<li>Code that involves user variables: <tt>x = 1; x = x + 1; </tt></li>
-<li>Values that are implicit in the structure of your AST, such as the phi node
+<li>Values that are implicit in the structure of your AST, such as the Phi node
in this case.</li>
</ol>
<p>In <a href="LangImpl7.html">Chapter 7</a> of this tutorial ("mutable
variables"), we'll talk about #1
in depth. For now, just believe me that you don't need SSA construction to
-handle them. For #2, you have the choice of using the techniques that we will
-describe for #1, or you can insert Phi nodes directly if convenient. In this
+handle this case. For #2, you have the choice of using the techniques that we will
+describe for #1, or you can insert Phi nodes directly, if convenient. In this
case, it is really really easy to generate the Phi node, so we choose to do it
directly.</p>
@@ -369,7 +369,7 @@ Value *IfExprAST::Codegen() {
</pre>
</div>
-<p>This code is straight-forward and similar to what we saw before. We emit the
+<p>This code is straightforward and similar to what we saw before. We emit the
expression for the condition, then compare that value to zero to get a truth
value as a 1-bit (bool) value.</p>
@@ -395,7 +395,7 @@ block for its "parent" (the function it is currently embedded into).</p>
<p>Once it has that, it creates three blocks. Note that it passes "TheFunction"
into the constructor for the "then" block. This causes the constructor to
-automatically insert the new block onto the end of the specified function. The
+automatically insert the new block into the end of the specified function. The
other two blocks are created, but aren't yet inserted into the function.</p>
<p>Once the blocks are created, we can emit the conditional branch that chooses
@@ -427,7 +427,7 @@ insertion point to be at the end of the specified block. However, since the
block. :)</p>
<p>Once the insertion point is set, we recursively codegen the "then" expression
-from the AST. To finish off the then block, we create an unconditional branch
+from the AST. To finish off the "then" block, we create an unconditional branch
to the merge block. One interesting (and very important) aspect of the LLVM IR
is that it <a href="../LangRef.html#functionstructure">requires all basic blocks
to be "terminated"</a> with a <a href="../LangRef.html#terminators">control flow
@@ -439,7 +439,7 @@ violate this rule, the verifier will emit an error.</p>
is that when we create the Phi node in the merge block, we need to set up the
block/value pairs that indicate how the Phi will work. Importantly, the Phi
node expects to have an entry for each predecessor of the block in the CFG. Why
-then are we getting the current block when we just set it to ThenBB 5 lines
+then, are we getting the current block when we just set it to ThenBB 5 lines
above? The problem is that the "Then" expression may actually itself change the
block that the Builder is emitting into if, for example, it contains a nested
"if/then/else" expression. Because calling Codegen recursively could
@@ -492,7 +492,7 @@ the if/then/else expression. In our example above, this returned value will
feed into the code for the top-level function, which will create the return
instruction.</p>
-<p>Overall, we now have the ability to execution conditional code in
+<p>Overall, we now have the ability to execute conditional code in
Kaleidoscope. With this extension, Kaleidoscope is a fairly complete language
that can calculate a wide variety of numeric functions. Next up we'll add
another useful expression that is familiar from non-functional languages...</p>
@@ -571,7 +571,7 @@ the 'for' Loop</a></div>
<div class="doc_text">
-<p>The AST node is similarly simple. It basically boils down to capturing
+<p>The AST node is just as simple. It basically boils down to capturing
the variable name and the constituent expressions in the node.</p>
<div class="doc_code">
@@ -704,7 +704,7 @@ the 'for' Loop</a></div>
<div class="doc_text">
-<p>The first part of codegen is very simple: we just output the start expression
+<p>The first part of Codegen is very simple: we just output the start expression
for the loop value:</p>
<div class="doc_code">
@@ -804,7 +804,7 @@ references to it will naturally find it in the symbol table.</p>
</div>
<p>Now that the body is emitted, we compute the next value of the iteration
-variable by adding the step value or 1.0 if it isn't present. '<tt>NextVar</tt>'
+variable by adding the step value, or 1.0 if it isn't present. '<tt>NextVar</tt>'
will be the value of the loop variable on the next iteration of the loop.</p>
<div class="doc_code">
@@ -839,8 +839,7 @@ statement.</p>
</div>
<p>With the code for the body of the loop complete, we just need to finish up
-the control flow for it. This remembers the end block (for the phi node), then
-creates the block for the loop exit ("afterloop"). Based on the value of the
+the control flow for it. This code remembers the end block (for the phi node), then creates the block for the loop exit ("afterloop"). Based on the value of the
exit condition, it creates a conditional branch that chooses between executing
the loop again and exiting the loop. Any future code is emitted in the
"afterloop" block, so it sets the insertion position to it.</p>
@@ -869,8 +868,7 @@ the for loop. Finally, code generation of the for loop always returns 0.0, so
that is what we return from <tt>ForExprAST::Codegen</tt>.</p>
<p>With this, we conclude the "adding control flow to Kaleidoscope" chapter of
-the tutorial. We added two control flow constructs, and used them to motivate
-a couple of aspects of the LLVM IR that are important for front-end implementors
+the tutorial. In this chapter we added two control flow constructs, and used them to motivate a couple of aspects of the LLVM IR that are important for front-end implementors
to know. In the next chapter of our saga, we will get a bit crazier and add
<a href="LangImpl6.html">user-defined operators</a> to our poor innocent
language.</p>