mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-24 11:42:57 +01:00
5a2632da06
Many quoted code blocks were not in sync with the actual toy.cpp files. Improve tutorial text slightly in several places. Added some step descriptions crucial to avoid crashes (like InitializeNativeTarget* calls). Solve/workaround problems with Windows (JIT'ed method not found, using custom and standard library functions from host process). Patch by: Moritz Kroll <moritz.kroll@gmx.de> Differential Revision: https://reviews.llvm.org/D29864 llvm-svn: 294870
769 lines
31 KiB
ReStructuredText
769 lines
31 KiB
ReStructuredText
============================================================
|
|
Kaleidoscope: Extending the Language: User-defined Operators
|
|
============================================================
|
|
|
|
.. contents::
|
|
:local:
|
|
|
|
Chapter 6 Introduction
|
|
======================
|
|
|
|
Welcome to Chapter 6 of the "`Implementing a language with
|
|
LLVM <index.html>`_" tutorial. At this point in our tutorial, we now
|
|
have a fully functional language that is fairly minimal, but also
|
|
useful. There is still one big problem with it, however. Our language
|
|
doesn't have many useful operators (like division, logical negation, or
|
|
even any comparisons besides less-than).
|
|
|
|
This chapter of the tutorial takes a wild digression into adding
|
|
user-defined operators to the simple and beautiful Kaleidoscope
|
|
language. This digression now gives us a simple and ugly language in
|
|
some ways, but also a powerful one at the same time. One of the great
|
|
things about creating your own language is that you get to decide what
|
|
is good or bad. In this tutorial we'll assume that it is okay to use
|
|
this as a way to show some interesting parsing techniques.
|
|
|
|
At the end of this tutorial, we'll run through an example Kaleidoscope
|
|
application that `renders the Mandelbrot set <#kicking-the-tires>`_. This gives an
|
|
example of what you can build with Kaleidoscope and its feature set.
|
|
|
|
User-defined Operators: the Idea
|
|
================================
|
|
|
|
The "operator overloading" that we will add to Kaleidoscope is more
|
|
general than in languages like C++. In C++, you are only allowed to
|
|
redefine existing operators: you can't programmatically change the
|
|
grammar, introduce new operators, change precedence levels, etc. In this
|
|
chapter, we will add this capability to Kaleidoscope, which will let the
|
|
user round out the set of operators that are supported.
|
|
|
|
The point of going into user-defined operators in a tutorial like this
|
|
is to show the power and flexibility of using a hand-written parser.
|
|
Thus far, the parser we have been implementing uses recursive descent
|
|
for most parts of the grammar and operator precedence parsing for the
|
|
expressions. See `Chapter 2 <LangImpl2.html>`_ for details. By
|
|
using operator precedence parsing, it is very easy to allow
|
|
the programmer to introduce new operators into the grammar: the grammar
|
|
is dynamically extensible as the JIT runs.
|
|
|
|
The two specific features we'll add are programmable unary operators
|
|
(right now, Kaleidoscope has no unary operators at all) as well as
|
|
binary operators. An example of this is:
|
|
|
|
::
|
|
|
|
# Logical unary not.
|
|
def unary!(v)
|
|
if v then
|
|
0
|
|
else
|
|
1;
|
|
|
|
# Define > with the same precedence as <.
|
|
def binary> 10 (LHS RHS)
|
|
RHS < LHS;
|
|
|
|
# Binary "logical or", (note that it does not "short circuit")
|
|
def binary| 5 (LHS RHS)
|
|
if LHS then
|
|
1
|
|
else if RHS then
|
|
1
|
|
else
|
|
0;
|
|
|
|
# Define = with slightly lower precedence than relationals.
|
|
def binary= 9 (LHS RHS)
|
|
!(LHS < RHS | LHS > RHS);
|
|
|
|
Many languages aspire to being able to implement their standard runtime
|
|
library in the language itself. In Kaleidoscope, we can implement
|
|
significant parts of the language in the library!
|
|
|
|
We will break down implementation of these features into two parts:
|
|
implementing support for user-defined binary operators and adding unary
|
|
operators.
|
|
|
|
User-defined Binary Operators
|
|
=============================
|
|
|
|
Adding support for user-defined binary operators is pretty simple with
|
|
our current framework. We'll first add support for the unary/binary
|
|
keywords:
|
|
|
|
.. code-block:: c++
|
|
|
|
enum Token {
|
|
...
|
|
// operators
|
|
tok_binary = -11,
|
|
tok_unary = -12
|
|
};
|
|
...
|
|
static int gettok() {
|
|
...
|
|
if (IdentifierStr == "for")
|
|
return tok_for;
|
|
if (IdentifierStr == "in")
|
|
return tok_in;
|
|
if (IdentifierStr == "binary")
|
|
return tok_binary;
|
|
if (IdentifierStr == "unary")
|
|
return tok_unary;
|
|
return tok_identifier;
|
|
|
|
This just adds lexer support for the unary and binary keywords, like we
|
|
did in `previous chapters <LangImpl5.html#lexer-extensions-for-if-then-else>`_. One nice thing
|
|
about our current AST, is that we represent binary operators with full
|
|
generalisation by using their ASCII code as the opcode. For our extended
|
|
operators, we'll use this same representation, so we don't need any new
|
|
AST or parser support.
|
|
|
|
On the other hand, we have to be able to represent the definitions of
|
|
these new operators, in the "def binary\| 5" part of the function
|
|
definition. In our grammar so far, the "name" for the function
|
|
definition is parsed as the "prototype" production and into the
|
|
``PrototypeAST`` AST node. To represent our new user-defined operators
|
|
as prototypes, we have to extend the ``PrototypeAST`` AST node like
|
|
this:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// PrototypeAST - This class represents the "prototype" for a function,
|
|
/// which captures its argument names as well as if it is an operator.
|
|
class PrototypeAST {
|
|
std::string Name;
|
|
std::vector<std::string> Args;
|
|
bool IsOperator;
|
|
unsigned Precedence; // Precedence if a binary op.
|
|
|
|
public:
|
|
PrototypeAST(const std::string &name, std::vector<std::string> Args,
|
|
bool IsOperator = false, unsigned Prec = 0)
|
|
: Name(name), Args(std::move(Args)), IsOperator(IsOperator),
|
|
Precedence(Prec) {}
|
|
|
|
Function *codegen();
|
|
const std::string &getName() const { return Name; }
|
|
|
|
bool isUnaryOp() const { return IsOperator && Args.size() == 1; }
|
|
bool isBinaryOp() const { return IsOperator && Args.size() == 2; }
|
|
|
|
char getOperatorName() const {
|
|
assert(isUnaryOp() || isBinaryOp());
|
|
return Name[Name.size() - 1];
|
|
}
|
|
|
|
unsigned getBinaryPrecedence() const { return Precedence; }
|
|
};
|
|
|
|
Basically, in addition to knowing a name for the prototype, we now keep
|
|
track of whether it was an operator, and if it was, what precedence
|
|
level the operator is at. The precedence is only used for binary
|
|
operators (as you'll see below, it just doesn't apply for unary
|
|
operators). Now that we have a way to represent the prototype for a
|
|
user-defined operator, we need to parse it:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// prototype
|
|
/// ::= id '(' id* ')'
|
|
/// ::= binary LETTER number? (id, id)
|
|
static std::unique_ptr<PrototypeAST> ParsePrototype() {
|
|
std::string FnName;
|
|
|
|
unsigned Kind = 0; // 0 = identifier, 1 = unary, 2 = binary.
|
|
unsigned BinaryPrecedence = 30;
|
|
|
|
switch (CurTok) {
|
|
default:
|
|
return LogErrorP("Expected function name in prototype");
|
|
case tok_identifier:
|
|
FnName = IdentifierStr;
|
|
Kind = 0;
|
|
getNextToken();
|
|
break;
|
|
case tok_binary:
|
|
getNextToken();
|
|
if (!isascii(CurTok))
|
|
return LogErrorP("Expected binary operator");
|
|
FnName = "binary";
|
|
FnName += (char)CurTok;
|
|
Kind = 2;
|
|
getNextToken();
|
|
|
|
// Read the precedence if present.
|
|
if (CurTok == tok_number) {
|
|
if (NumVal < 1 || NumVal > 100)
|
|
return LogErrorP("Invalid precedence: must be 1..100");
|
|
BinaryPrecedence = (unsigned)NumVal;
|
|
getNextToken();
|
|
}
|
|
break;
|
|
}
|
|
|
|
if (CurTok != '(')
|
|
return LogErrorP("Expected '(' in prototype");
|
|
|
|
std::vector<std::string> ArgNames;
|
|
while (getNextToken() == tok_identifier)
|
|
ArgNames.push_back(IdentifierStr);
|
|
if (CurTok != ')')
|
|
return LogErrorP("Expected ')' in prototype");
|
|
|
|
// success.
|
|
getNextToken(); // eat ')'.
|
|
|
|
// Verify right number of names for operator.
|
|
if (Kind && ArgNames.size() != Kind)
|
|
return LogErrorP("Invalid number of operands for operator");
|
|
|
|
return llvm::make_unique<PrototypeAST>(FnName, std::move(ArgNames), Kind != 0,
|
|
BinaryPrecedence);
|
|
}
|
|
|
|
This is all fairly straightforward parsing code, and we have already
|
|
seen a lot of similar code in the past. One interesting part about the
|
|
code above is the couple lines that set up ``FnName`` for binary
|
|
operators. This builds names like "binary@" for a newly defined "@"
|
|
operator. It then takes advantage of the fact that symbol names in the
|
|
LLVM symbol table are allowed to have any character in them, including
|
|
embedded nul characters.
|
|
|
|
The next interesting thing to add, is codegen support for these binary
|
|
operators. Given our current structure, this is a simple addition of a
|
|
default case for our existing binary operator node:
|
|
|
|
.. code-block:: c++
|
|
|
|
Value *BinaryExprAST::codegen() {
|
|
Value *L = LHS->codegen();
|
|
Value *R = RHS->codegen();
|
|
if (!L || !R)
|
|
return nullptr;
|
|
|
|
switch (Op) {
|
|
case '+':
|
|
return Builder.CreateFAdd(L, R, "addtmp");
|
|
case '-':
|
|
return Builder.CreateFSub(L, R, "subtmp");
|
|
case '*':
|
|
return Builder.CreateFMul(L, R, "multmp");
|
|
case '<':
|
|
L = Builder.CreateFCmpULT(L, R, "cmptmp");
|
|
// Convert bool 0/1 to double 0.0 or 1.0
|
|
return Builder.CreateUIToFP(L, Type::getDoubleTy(TheContext),
|
|
"booltmp");
|
|
default:
|
|
break;
|
|
}
|
|
|
|
// If it wasn't a builtin binary operator, it must be a user defined one. Emit
|
|
// a call to it.
|
|
Function *F = getFunction(std::string("binary") + Op);
|
|
assert(F && "binary operator not found!");
|
|
|
|
Value *Ops[2] = { L, R };
|
|
return Builder.CreateCall(F, Ops, "binop");
|
|
}
|
|
|
|
As you can see above, the new code is actually really simple. It just
|
|
does a lookup for the appropriate operator in the symbol table and
|
|
generates a function call to it. Since user-defined operators are just
|
|
built as normal functions (because the "prototype" boils down to a
|
|
function with the right name) everything falls into place.
|
|
|
|
The final piece of code we are missing, is a bit of top-level magic:
|
|
|
|
.. code-block:: c++
|
|
|
|
Function *FunctionAST::codegen() {
|
|
// Transfer ownership of the prototype to the FunctionProtos map, but keep a
|
|
// reference to it for use below.
|
|
auto &P = *Proto;
|
|
FunctionProtos[Proto->getName()] = std::move(Proto);
|
|
Function *TheFunction = getFunction(P.getName());
|
|
if (!TheFunction)
|
|
return nullptr;
|
|
|
|
// If this is an operator, install it.
|
|
if (P.isBinaryOp())
|
|
BinopPrecedence[P.getOperatorName()] = P.getBinaryPrecedence();
|
|
|
|
// Create a new basic block to start insertion into.
|
|
BasicBlock *BB = BasicBlock::Create(TheContext, "entry", TheFunction);
|
|
...
|
|
|
|
Basically, before codegening a function, if it is a user-defined
|
|
operator, we register it in the precedence table. This allows the binary
|
|
operator parsing logic we already have in place to handle it. Since we
|
|
are working on a fully-general operator precedence parser, this is all
|
|
we need to do to "extend the grammar".
|
|
|
|
Now we have useful user-defined binary operators. This builds a lot on
|
|
the previous framework we built for other operators. Adding unary
|
|
operators is a bit more challenging, because we don't have any framework
|
|
for it yet - lets see what it takes.
|
|
|
|
User-defined Unary Operators
|
|
============================
|
|
|
|
Since we don't currently support unary operators in the Kaleidoscope
|
|
language, we'll need to add everything to support them. Above, we added
|
|
simple support for the 'unary' keyword to the lexer. In addition to
|
|
that, we need an AST node:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// UnaryExprAST - Expression class for a unary operator.
|
|
class UnaryExprAST : public ExprAST {
|
|
char Opcode;
|
|
std::unique_ptr<ExprAST> Operand;
|
|
|
|
public:
|
|
UnaryExprAST(char Opcode, std::unique_ptr<ExprAST> Operand)
|
|
: Opcode(Opcode), Operand(std::move(Operand)) {}
|
|
|
|
Value *codegen() override;
|
|
};
|
|
|
|
This AST node is very simple and obvious by now. It directly mirrors the
|
|
binary operator AST node, except that it only has one child. With this,
|
|
we need to add the parsing logic. Parsing a unary operator is pretty
|
|
simple: we'll add a new function to do it:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// unary
|
|
/// ::= primary
|
|
/// ::= '!' unary
|
|
static std::unique_ptr<ExprAST> ParseUnary() {
|
|
// If the current token is not an operator, it must be a primary expr.
|
|
if (!isascii(CurTok) || CurTok == '(' || CurTok == ',')
|
|
return ParsePrimary();
|
|
|
|
// If this is a unary operator, read it.
|
|
int Opc = CurTok;
|
|
getNextToken();
|
|
if (auto Operand = ParseUnary())
|
|
return llvm::make_unique<UnaryExprAST>(Opc, std::move(Operand));
|
|
return nullptr;
|
|
}
|
|
|
|
The grammar we add is pretty straightforward here. If we see a unary
|
|
operator when parsing a primary operator, we eat the operator as a
|
|
prefix and parse the remaining piece as another unary operator. This
|
|
allows us to handle multiple unary operators (e.g. "!!x"). Note that
|
|
unary operators can't have ambiguous parses like binary operators can,
|
|
so there is no need for precedence information.
|
|
|
|
The problem with this function, is that we need to call ParseUnary from
|
|
somewhere. To do this, we change previous callers of ParsePrimary to
|
|
call ParseUnary instead:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// binoprhs
|
|
/// ::= ('+' unary)*
|
|
static std::unique_ptr<ExprAST> ParseBinOpRHS(int ExprPrec,
|
|
std::unique_ptr<ExprAST> LHS) {
|
|
...
|
|
// Parse the unary expression after the binary operator.
|
|
auto RHS = ParseUnary();
|
|
if (!RHS)
|
|
return nullptr;
|
|
...
|
|
}
|
|
/// expression
|
|
/// ::= unary binoprhs
|
|
///
|
|
static std::unique_ptr<ExprAST> ParseExpression() {
|
|
auto LHS = ParseUnary();
|
|
if (!LHS)
|
|
return nullptr;
|
|
|
|
return ParseBinOpRHS(0, std::move(LHS));
|
|
}
|
|
|
|
With these two simple changes, we are now able to parse unary operators
|
|
and build the AST for them. Next up, we need to add parser support for
|
|
prototypes, to parse the unary operator prototype. We extend the binary
|
|
operator code above with:
|
|
|
|
.. code-block:: c++
|
|
|
|
/// prototype
|
|
/// ::= id '(' id* ')'
|
|
/// ::= binary LETTER number? (id, id)
|
|
/// ::= unary LETTER (id)
|
|
static std::unique_ptr<PrototypeAST> ParsePrototype() {
|
|
std::string FnName;
|
|
|
|
unsigned Kind = 0; // 0 = identifier, 1 = unary, 2 = binary.
|
|
unsigned BinaryPrecedence = 30;
|
|
|
|
switch (CurTok) {
|
|
default:
|
|
return LogErrorP("Expected function name in prototype");
|
|
case tok_identifier:
|
|
FnName = IdentifierStr;
|
|
Kind = 0;
|
|
getNextToken();
|
|
break;
|
|
case tok_unary:
|
|
getNextToken();
|
|
if (!isascii(CurTok))
|
|
return LogErrorP("Expected unary operator");
|
|
FnName = "unary";
|
|
FnName += (char)CurTok;
|
|
Kind = 1;
|
|
getNextToken();
|
|
break;
|
|
case tok_binary:
|
|
...
|
|
|
|
As with binary operators, we name unary operators with a name that
|
|
includes the operator character. This assists us at code generation
|
|
time. Speaking of, the final piece we need to add is codegen support for
|
|
unary operators. It looks like this:
|
|
|
|
.. code-block:: c++
|
|
|
|
Value *UnaryExprAST::codegen() {
|
|
Value *OperandV = Operand->codegen();
|
|
if (!OperandV)
|
|
return nullptr;
|
|
|
|
Function *F = getFunction(std::string("unary") + Opcode);
|
|
if (!F)
|
|
return LogErrorV("Unknown unary operator");
|
|
|
|
return Builder.CreateCall(F, OperandV, "unop");
|
|
}
|
|
|
|
This code is similar to, but simpler than, the code for binary
|
|
operators. It is simpler primarily because it doesn't need to handle any
|
|
predefined operators.
|
|
|
|
Kicking the Tires
|
|
=================
|
|
|
|
It is somewhat hard to believe, but with a few simple extensions we've
|
|
covered in the last chapters, we have grown a real-ish language. With
|
|
this, we can do a lot of interesting things, including I/O, math, and a
|
|
bunch of other things. For example, we can now add a nice sequencing
|
|
operator (printd is defined to print out the specified value and a
|
|
newline):
|
|
|
|
::
|
|
|
|
ready> extern printd(x);
|
|
Read extern:
|
|
declare double @printd(double)
|
|
|
|
ready> def binary : 1 (x y) 0; # Low-precedence operator that ignores operands.
|
|
...
|
|
ready> printd(123) : printd(456) : printd(789);
|
|
123.000000
|
|
456.000000
|
|
789.000000
|
|
Evaluated to 0.000000
|
|
|
|
We can also define a bunch of other "primitive" operations, such as:
|
|
|
|
::
|
|
|
|
# Logical unary not.
|
|
def unary!(v)
|
|
if v then
|
|
0
|
|
else
|
|
1;
|
|
|
|
# Unary negate.
|
|
def unary-(v)
|
|
0-v;
|
|
|
|
# Define > with the same precedence as <.
|
|
def binary> 10 (LHS RHS)
|
|
RHS < LHS;
|
|
|
|
# Binary logical or, which does not short circuit.
|
|
def binary| 5 (LHS RHS)
|
|
if LHS then
|
|
1
|
|
else if RHS then
|
|
1
|
|
else
|
|
0;
|
|
|
|
# Binary logical and, which does not short circuit.
|
|
def binary& 6 (LHS RHS)
|
|
if !LHS then
|
|
0
|
|
else
|
|
!!RHS;
|
|
|
|
# Define = with slightly lower precedence than relationals.
|
|
def binary = 9 (LHS RHS)
|
|
!(LHS < RHS | LHS > RHS);
|
|
|
|
# Define ':' for sequencing: as a low-precedence operator that ignores operands
|
|
# and just returns the RHS.
|
|
def binary : 1 (x y) y;
|
|
|
|
Given the previous if/then/else support, we can also define interesting
|
|
functions for I/O. For example, the following prints out a character
|
|
whose "density" reflects the value passed in: the lower the value, the
|
|
denser the character:
|
|
|
|
::
|
|
|
|
ready> extern putchard(char);
|
|
...
|
|
ready> def printdensity(d)
|
|
if d > 8 then
|
|
putchard(32) # ' '
|
|
else if d > 4 then
|
|
putchard(46) # '.'
|
|
else if d > 2 then
|
|
putchard(43) # '+'
|
|
else
|
|
putchard(42); # '*'
|
|
...
|
|
ready> printdensity(1): printdensity(2): printdensity(3):
|
|
printdensity(4): printdensity(5): printdensity(9):
|
|
putchard(10);
|
|
**++.
|
|
Evaluated to 0.000000
|
|
|
|
Based on these simple primitive operations, we can start to define more
|
|
interesting things. For example, here's a little function that determines
|
|
the number of iterations it takes for a certain function in the complex
|
|
plane to diverge:
|
|
|
|
::
|
|
|
|
# Determine whether the specific location diverges.
|
|
# Solve for z = z^2 + c in the complex plane.
|
|
def mandelconverger(real imag iters creal cimag)
|
|
if iters > 255 | (real*real + imag*imag > 4) then
|
|
iters
|
|
else
|
|
mandelconverger(real*real - imag*imag + creal,
|
|
2*real*imag + cimag,
|
|
iters+1, creal, cimag);
|
|
|
|
# Return the number of iterations required for the iteration to escape
|
|
def mandelconverge(real imag)
|
|
mandelconverger(real, imag, 0, real, imag);
|
|
|
|
This "``z = z2 + c``" function is a beautiful little creature that is
|
|
the basis for computation of the `Mandelbrot
|
|
Set <http://en.wikipedia.org/wiki/Mandelbrot_set>`_. Our
|
|
``mandelconverge`` function returns the number of iterations that it
|
|
takes for a complex orbit to escape, saturating to 255. This is not a
|
|
very useful function by itself, but if you plot its value over a
|
|
two-dimensional plane, you can see the Mandelbrot set. Given that we are
|
|
limited to using putchard here, our amazing graphical output is limited,
|
|
but we can whip together something using the density plotter above:
|
|
|
|
::
|
|
|
|
# Compute and plot the mandelbrot set with the specified 2 dimensional range
|
|
# info.
|
|
def mandelhelp(xmin xmax xstep ymin ymax ystep)
|
|
for y = ymin, y < ymax, ystep in (
|
|
(for x = xmin, x < xmax, xstep in
|
|
printdensity(mandelconverge(x,y)))
|
|
: putchard(10)
|
|
)
|
|
|
|
# mandel - This is a convenient helper function for plotting the mandelbrot set
|
|
# from the specified position with the specified Magnification.
|
|
def mandel(realstart imagstart realmag imagmag)
|
|
mandelhelp(realstart, realstart+realmag*78, realmag,
|
|
imagstart, imagstart+imagmag*40, imagmag);
|
|
|
|
Given this, we can try plotting out the mandelbrot set! Lets try it out:
|
|
|
|
::
|
|
|
|
ready> mandel(-2.3, -1.3, 0.05, 0.07);
|
|
*******************************+++++++++++*************************************
|
|
*************************+++++++++++++++++++++++*******************************
|
|
**********************+++++++++++++++++++++++++++++****************************
|
|
*******************+++++++++++++++++++++.. ...++++++++*************************
|
|
*****************++++++++++++++++++++++.... ...+++++++++***********************
|
|
***************+++++++++++++++++++++++..... ...+++++++++*********************
|
|
**************+++++++++++++++++++++++.... ....+++++++++********************
|
|
*************++++++++++++++++++++++...... .....++++++++*******************
|
|
************+++++++++++++++++++++....... .......+++++++******************
|
|
***********+++++++++++++++++++.... ... .+++++++*****************
|
|
**********+++++++++++++++++....... .+++++++****************
|
|
*********++++++++++++++........... ...+++++++***************
|
|
********++++++++++++............ ...++++++++**************
|
|
********++++++++++... .......... .++++++++**************
|
|
*******+++++++++..... .+++++++++*************
|
|
*******++++++++...... ..+++++++++*************
|
|
*******++++++....... ..+++++++++*************
|
|
*******+++++...... ..+++++++++*************
|
|
*******.... .... ...+++++++++*************
|
|
*******.... . ...+++++++++*************
|
|
*******+++++...... ...+++++++++*************
|
|
*******++++++....... ..+++++++++*************
|
|
*******++++++++...... .+++++++++*************
|
|
*******+++++++++..... ..+++++++++*************
|
|
********++++++++++... .......... .++++++++**************
|
|
********++++++++++++............ ...++++++++**************
|
|
*********++++++++++++++.......... ...+++++++***************
|
|
**********++++++++++++++++........ .+++++++****************
|
|
**********++++++++++++++++++++.... ... ..+++++++****************
|
|
***********++++++++++++++++++++++....... .......++++++++*****************
|
|
************+++++++++++++++++++++++...... ......++++++++******************
|
|
**************+++++++++++++++++++++++.... ....++++++++********************
|
|
***************+++++++++++++++++++++++..... ...+++++++++*********************
|
|
*****************++++++++++++++++++++++.... ...++++++++***********************
|
|
*******************+++++++++++++++++++++......++++++++*************************
|
|
*********************++++++++++++++++++++++.++++++++***************************
|
|
*************************+++++++++++++++++++++++*******************************
|
|
******************************+++++++++++++************************************
|
|
*******************************************************************************
|
|
*******************************************************************************
|
|
*******************************************************************************
|
|
Evaluated to 0.000000
|
|
ready> mandel(-2, -1, 0.02, 0.04);
|
|
**************************+++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
***********************++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
*********************+++++++++++++++++++++++++++++++++++++++++++++++++++++++++.
|
|
*******************+++++++++++++++++++++++++++++++++++++++++++++++++++++++++...
|
|
*****************+++++++++++++++++++++++++++++++++++++++++++++++++++++++++.....
|
|
***************++++++++++++++++++++++++++++++++++++++++++++++++++++++++........
|
|
**************++++++++++++++++++++++++++++++++++++++++++++++++++++++...........
|
|
************+++++++++++++++++++++++++++++++++++++++++++++++++++++..............
|
|
***********++++++++++++++++++++++++++++++++++++++++++++++++++........ .
|
|
**********++++++++++++++++++++++++++++++++++++++++++++++.............
|
|
********+++++++++++++++++++++++++++++++++++++++++++..................
|
|
*******+++++++++++++++++++++++++++++++++++++++.......................
|
|
******+++++++++++++++++++++++++++++++++++...........................
|
|
*****++++++++++++++++++++++++++++++++............................
|
|
*****++++++++++++++++++++++++++++...............................
|
|
****++++++++++++++++++++++++++...... .........................
|
|
***++++++++++++++++++++++++......... ...... ...........
|
|
***++++++++++++++++++++++............
|
|
**+++++++++++++++++++++..............
|
|
**+++++++++++++++++++................
|
|
*++++++++++++++++++.................
|
|
*++++++++++++++++............ ...
|
|
*++++++++++++++..............
|
|
*+++....++++................
|
|
*.......... ...........
|
|
*
|
|
*.......... ...........
|
|
*+++....++++................
|
|
*++++++++++++++..............
|
|
*++++++++++++++++............ ...
|
|
*++++++++++++++++++.................
|
|
**+++++++++++++++++++................
|
|
**+++++++++++++++++++++..............
|
|
***++++++++++++++++++++++............
|
|
***++++++++++++++++++++++++......... ...... ...........
|
|
****++++++++++++++++++++++++++...... .........................
|
|
*****++++++++++++++++++++++++++++...............................
|
|
*****++++++++++++++++++++++++++++++++............................
|
|
******+++++++++++++++++++++++++++++++++++...........................
|
|
*******+++++++++++++++++++++++++++++++++++++++.......................
|
|
********+++++++++++++++++++++++++++++++++++++++++++..................
|
|
Evaluated to 0.000000
|
|
ready> mandel(-0.9, -1.4, 0.02, 0.03);
|
|
*******************************************************************************
|
|
*******************************************************************************
|
|
*******************************************************************************
|
|
**********+++++++++++++++++++++************************************************
|
|
*+++++++++++++++++++++++++++++++++++++++***************************************
|
|
+++++++++++++++++++++++++++++++++++++++++++++**********************************
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++*****************************
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++*************************
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++**********************
|
|
+++++++++++++++++++++++++++++++++.........++++++++++++++++++*******************
|
|
+++++++++++++++++++++++++++++++.... ......+++++++++++++++++++****************
|
|
+++++++++++++++++++++++++++++....... ........+++++++++++++++++++**************
|
|
++++++++++++++++++++++++++++........ ........++++++++++++++++++++************
|
|
+++++++++++++++++++++++++++......... .. ...+++++++++++++++++++++**********
|
|
++++++++++++++++++++++++++........... ....++++++++++++++++++++++********
|
|
++++++++++++++++++++++++............. .......++++++++++++++++++++++******
|
|
+++++++++++++++++++++++............. ........+++++++++++++++++++++++****
|
|
++++++++++++++++++++++........... ..........++++++++++++++++++++++***
|
|
++++++++++++++++++++........... .........++++++++++++++++++++++*
|
|
++++++++++++++++++............ ...........++++++++++++++++++++
|
|
++++++++++++++++............... .............++++++++++++++++++
|
|
++++++++++++++................. ...............++++++++++++++++
|
|
++++++++++++.................. .................++++++++++++++
|
|
+++++++++.................. .................+++++++++++++
|
|
++++++........ . ......... ..++++++++++++
|
|
++............ ...... ....++++++++++
|
|
.............. ...++++++++++
|
|
.............. ....+++++++++
|
|
.............. .....++++++++
|
|
............. ......++++++++
|
|
........... .......++++++++
|
|
......... ........+++++++
|
|
......... ........+++++++
|
|
......... ....+++++++
|
|
........ ...+++++++
|
|
....... ...+++++++
|
|
....+++++++
|
|
.....+++++++
|
|
....+++++++
|
|
....+++++++
|
|
....+++++++
|
|
Evaluated to 0.000000
|
|
ready> ^D
|
|
|
|
At this point, you may be starting to realize that Kaleidoscope is a
|
|
real and powerful language. It may not be self-similar :), but it can be
|
|
used to plot things that are!
|
|
|
|
With this, we conclude the "adding user-defined operators" chapter of
|
|
the tutorial. We have successfully augmented our language, adding the
|
|
ability to extend the language in the library, and we have shown how
|
|
this can be used to build a simple but interesting end-user application
|
|
in Kaleidoscope. At this point, Kaleidoscope can build a variety of
|
|
applications that are functional and can call functions with
|
|
side-effects, but it can't actually define and mutate a variable itself.
|
|
|
|
Strikingly, variable mutation is an important feature of some languages,
|
|
and it is not at all obvious how to `add support for mutable
|
|
variables <LangImpl7.html>`_ without having to add an "SSA construction"
|
|
phase to your front-end. In the next chapter, we will describe how you
|
|
can add variable mutation without building SSA in your front-end.
|
|
|
|
Full Code Listing
|
|
=================
|
|
|
|
Here is the complete code listing for our running example, enhanced with
|
|
the support for user-defined operators. To build this example, use:
|
|
|
|
.. code-block:: bash
|
|
|
|
# Compile
|
|
clang++ -g toy.cpp `llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native` -O3 -o toy
|
|
# Run
|
|
./toy
|
|
|
|
On some platforms, you will need to specify -rdynamic or
|
|
-Wl,--export-dynamic when linking. This ensures that symbols defined in
|
|
the main executable are exported to the dynamic linker and so are
|
|
available for symbol resolution at run time. This is not needed if you
|
|
compile your support code into a shared library, although doing that
|
|
will cause problems on Windows.
|
|
|
|
Here is the code:
|
|
|
|
.. literalinclude:: ../../examples/Kaleidoscope/Chapter6/toy.cpp
|
|
:language: c++
|
|
|
|
`Next: Extending the language: mutable variables / SSA
|
|
construction <LangImpl07.html>`_
|
|
|