mirror of
				https://github.com/c64scene-ar/llvm-6502.git
				synced 2025-10-31 08:16:47 +00:00 
			
		
		
		
	Several LLVM headers are moved. The code listings in LLVM tutorial are not updated yet. This CL removes the code replica in the .rst, and replace them with a literalinclude directive, so that sphinx can include the latest code automatically. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183607 91177308-0d34-0410-b5e6-96231b3b80d8
		
			
				
	
	
		
			751 lines
		
	
	
		
			30 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			751 lines
		
	
	
		
			30 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 <#example>`_. 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 languages like C++. In C++, you are only allowed to
 | |
| redefine existing operators: you can't programatically 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. Without
 | |
| using operator precedence parsing, it would be very difficult 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#iflexer>`_. 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, const std::vector<std::string> &args,
 | |
|                    bool isoperator = false, unsigned prec = 0)
 | |
|       : Name(name), Args(args), isOperator(isoperator), Precedence(prec) {}
 | |
| 
 | |
|       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; }
 | |
| 
 | |
|       Function *Codegen();
 | |
|     };
 | |
| 
 | |
| 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 PrototypeAST *ParsePrototype() {
 | |
|       std::string FnName;
 | |
| 
 | |
|       unsigned Kind = 0;  // 0 = identifier, 1 = unary, 2 = binary.
 | |
|       unsigned BinaryPrecedence = 30;
 | |
| 
 | |
|       switch (CurTok) {
 | |
|       default:
 | |
|         return ErrorP("Expected function name in prototype");
 | |
|       case tok_identifier:
 | |
|         FnName = IdentifierStr;
 | |
|         Kind = 0;
 | |
|         getNextToken();
 | |
|         break;
 | |
|       case tok_binary:
 | |
|         getNextToken();
 | |
|         if (!isascii(CurTok))
 | |
|           return ErrorP("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 ErrorP("Invalid precedecnce: must be 1..100");
 | |
|           BinaryPrecedence = (unsigned)NumVal;
 | |
|           getNextToken();
 | |
|         }
 | |
|         break;
 | |
|       }
 | |
| 
 | |
|       if (CurTok != '(')
 | |
|         return ErrorP("Expected '(' in prototype");
 | |
| 
 | |
|       std::vector<std::string> ArgNames;
 | |
|       while (getNextToken() == tok_identifier)
 | |
|         ArgNames.push_back(IdentifierStr);
 | |
|       if (CurTok != ')')
 | |
|         return ErrorP("Expected ')' in prototype");
 | |
| 
 | |
|       // success.
 | |
|       getNextToken();  // eat ')'.
 | |
| 
 | |
|       // Verify right number of names for operator.
 | |
|       if (Kind && ArgNames.size() != Kind)
 | |
|         return ErrorP("Invalid number of operands for operator");
 | |
| 
 | |
|       return new PrototypeAST(FnName, 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. This 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 == 0 || R == 0) return 0;
 | |
| 
 | |
|       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(getGlobalContext()),
 | |
|                                     "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 = TheModule->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() {
 | |
|       NamedValues.clear();
 | |
| 
 | |
|       Function *TheFunction = Proto->Codegen();
 | |
|       if (TheFunction == 0)
 | |
|         return 0;
 | |
| 
 | |
|       // If this is an operator, install it.
 | |
|       if (Proto->isBinaryOp())
 | |
|         BinopPrecedence[Proto->getOperatorName()] = Proto->getBinaryPrecedence();
 | |
| 
 | |
|       // Create a new basic block to start insertion into.
 | |
|       BasicBlock *BB = BasicBlock::Create(getGlobalContext(), "entry", TheFunction);
 | |
|       Builder.SetInsertPoint(BB);
 | |
| 
 | |
|       if (Value *RetVal = Body->Codegen()) {
 | |
|         ...
 | |
| 
 | |
| 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;
 | |
|       ExprAST *Operand;
 | |
|     public:
 | |
|       UnaryExprAST(char opcode, ExprAST *operand)
 | |
|         : Opcode(opcode), Operand(operand) {}
 | |
|       virtual Value *Codegen();
 | |
|     };
 | |
| 
 | |
| 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 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 (ExprAST *Operand = ParseUnary())
 | |
|         return new UnaryExprAST(Opc, Operand);
 | |
|       return 0;
 | |
|     }
 | |
| 
 | |
| 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 ExprAST *ParseBinOpRHS(int ExprPrec, ExprAST *LHS) {
 | |
|       ...
 | |
|         // Parse the unary expression after the binary operator.
 | |
|         ExprAST *RHS = ParseUnary();
 | |
|         if (!RHS) return 0;
 | |
|       ...
 | |
|     }
 | |
|     /// expression
 | |
|     ///   ::= unary binoprhs
 | |
|     ///
 | |
|     static ExprAST *ParseExpression() {
 | |
|       ExprAST *LHS = ParseUnary();
 | |
|       if (!LHS) return 0;
 | |
| 
 | |
|       return ParseBinOpRHS(0, 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 PrototypeAST *ParsePrototype() {
 | |
|       std::string FnName;
 | |
| 
 | |
|       unsigned Kind = 0;  // 0 = identifier, 1 = unary, 2 = binary.
 | |
|       unsigned BinaryPrecedence = 30;
 | |
| 
 | |
|       switch (CurTok) {
 | |
|       default:
 | |
|         return ErrorP("Expected function name in prototype");
 | |
|       case tok_identifier:
 | |
|         FnName = IdentifierStr;
 | |
|         Kind = 0;
 | |
|         getNextToken();
 | |
|         break;
 | |
|       case tok_unary:
 | |
|         getNextToken();
 | |
|         if (!isascii(CurTok))
 | |
|           return ErrorP("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 == 0) return 0;
 | |
| 
 | |
|       Function *F = TheModule->getFunction(std::string("unary")+Opcode);
 | |
|       if (F == 0)
 | |
|         return ErrorV("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)
 | |
|     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 solves
 | |
| for the number of iterations it takes a function in the complex plane to
 | |
| converge:
 | |
| 
 | |
| ::
 | |
| 
 | |
|     # Determine whether the specific location diverges.
 | |
|     # Solve for z = z^2 + c in the complex plane.
 | |
|     def mandleconverger(real imag iters creal cimag)
 | |
|       if iters > 255 | (real*real + imag*imag > 4) then
 | |
|         iters
 | |
|       else
 | |
|         mandleconverger(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 mandleconverge(real imag)
 | |
|       mandleconverger(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 mandlebrot 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(mandleconverge(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 mandlebrot 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 if/then/else and for expressions.. To build this example, use:
 | |
| 
 | |
| .. code-block:: bash
 | |
| 
 | |
|     # Compile
 | |
|     clang++ -g toy.cpp `llvm-config --cppflags --ldflags --libs core jit 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 <LangImpl7.html>`_
 | |
| 
 |