Thnad's Revenge

A programming language implementation tale given at JRubyConf 2012 in Minneapolis, MN.

Transcript

1. Welcome to “Thnad’s Revenge,” a programming language implementation tale in three acts.
2. Not to be confused with...
3. http://en.wikipedia.org/wiki/Yars'_Revenge ...Yars’ Revenge, the awesome Atari video game from the ’80s.
4. Cucumber Recipes Ian Dees with Aslak Hellesøy and Matt Wynne pragprog/titles/JRUBY discount code: JRubyIanDees Before we get to the talk, let me make a couple of quick announcements. First, we’re updating the JRuby book this summer with a JRuby 1.7-ready PDF. To celebrate that, we’re offering a discount code on the book during the conference. Second, I’m working on a new book with the Cucumber folks, which has some JRuby/JVM stuff in it—if you’d like to be a tech reviewer, please find me after this talk.
5. I. Meet Thnad II. Enter the Frenemy III. Thnad’s Revenge (with apologies to Ira Glass) Act I, Meet Thnad, in which we encounter Thnad, a programming language built with JRuby and designed not for programmer happiness, but for implementer happiness. Act II, Enter the Frenemy, in which we meet a new Ruby runtime. Act III, Thnad's Revenge, in which we port Thnad to run on the Rubinius runtime and encounter some surprises along the way.
6. I. Meet Thnad Thnad is a programming language I created last summer as an excuse to learn some fun JRuby tools and see what it's like to write a compiler.
7. The name comes from a letter invented by Dr. Seuss in his book, “On Beyond Zebra.” Since most of the real letters are already taken by programming languages, a fictional one seems appropriate.
8. A Fictional Programming Language Optimized for Implementer Happiness Just as Ruby is optimized for programmer happiness, Thnad is optimized for implementer happiness. It was designed to be implemented with a minimum of time and effort, and a maximum amount of fun.
9. function factorial(n) { if (eq(n, 1)) { 1 } else { times(n, factorial(minus(n, 1))) } } print(factorial(4)) Here’s a sample Thnad program demonstrating all the major features. Thnad has integers, functions, conditionals, and... not much else. These minimal features were easy to add, thanks to the great tools available in the JRuby ecosystem (and other ecosystems, as we’ll see).
10. Thnad Features 1. Names and Numbers 2. Function Calls 3. Conditionals 4. Function Definitions In the next few minutes, we’re going to trace through each of these four language features, from parsing the source all the way to generating the final binary. We won’t show every single grammar rule, but we will hit the high points.
11. As Tom mentioned in his talk, there are a number of phases a piece of source code goes through during compilation.
12. Stages of Parsing tokenize parse transform emit These break down into four main stages in a typical language: finding the tokens or parts of speech of the text, parsing the tokens into an in-memory tree, transforming the tree, and generating the bytecode. We’re going to look at each of Thnad’s major features in the context of these stages.
13. 1. Names and Numbers First, let’s look at the easiest language feature: numbers and function parameters.
14. '42' :number "42" root {:number => '42'} Our parser needs to transform this input text into some kind of Ruby data structure.
15. Parslet kschiess.github.com/parslet I used a library called Parslet for that. Parslet handles the first two stages of compilation (tokenizing and parsing) using a Parsing Expression Grammar, or PEG. PEGs are like regular expressions attached to blocks of code. They sound like a hack, but there’s solid compiler theory behind them.
16. '42' :number "42" root rule(:number) { match('[0-9]').repeat(1).as(:number) >> space? } {:number => '42'} The rule at the bottom of the page is Parslet’s notation for matching one or more numbers followed by a optional space.
17. rule(:number => simple(:value)) { Number.new(value.to_i) } Thnad::Number.new(42) {:number => '42'} Thnad::Number :value 42 root :number "42" root Now for the third stage, transformation. We could generate the bytecode straight from the original tree, using a bunch of hard-to-test case statements. But it would be nicer to have a specific Ruby class for each Thnad language feature. The rule at the bottom of this slide tells Parslet to transform a Hash with a key called :number into an instance of a Number class we provide.
18. BiteScript github/headius/bitescript The final stage, outputting bytecode, is handled by the BiteScript library, which is basically a domain-specific language for emitting JVM opcodes.
19. main do ldc 42 ldc 1 invokestatic :Example, :baz, [int, int, int] returnvoid end Here's an example, just to get an idea of the flavor. To call a method, you just push the arguments onto the stack and then call a specific opcode, in this case invokestatic. The VM you're writing for is aware of classes, interfaces, and so on—you don't have to implement method lookup like you would with plain machine code.
20. “JVM Bytecode for Dummies” Charles Nutter, Øredev 2010 slideshare/CharlesNutter/redev-2010-jvm-bytecode-for-dummies When I first saw the BiteScript, I thought it was something you'd only need if you were doing deep JVM hacking. But when I read the slides from Charlie's presentation at Øredev, it clicked. This library takes me way back to my college days, when we'd write assembler programs for a really simple instruction set like MIPS. BiteScript evokes that same kind of feeling. I'd always thought the JVM would have a huge, crufty instruction set—but it's actually quite manageable to keep the most important parts of it in your head.
21. class Number < Struct.new :value def eval(context, builder) builder.ldc value end end We can generate the bytecode any way we want. One simple way is to give each of our classes an eval() method that takes a BiteScript generator and calls various methods on it to generate JVM instructions.
22. class Name < Struct.new :name def eval(context, builder) param_names = context[:params] || [] position = param_names.index(name) raise "Unknown parameter #{name}" unless position builder.iload position end end Dealing with passed-in parameters is nearly as easy as dealing with raw integers; we just look up the parameter name by position, and then push the nth parameter onto the stack.
23. 2. Function Calls The next major feature is function calls. Once we have those, we will be able to run a trivial Thnad program.
24. 'baz(42, foo)' {:funcall => {:name => 'baz', :args => [ {:arg => {:number => '42'}}]}} {:arg => {:name => 'foo'}}]}} :funcall :name :args "baz" :arg :arg :number "42" :name "foo" root We’re going to move a little faster here, to leave time for Rubinius. Here, we want to transform this source code into this Ruby data structure representing a function call.
25. Thnad::Funcall.new 'foo', [Thnad::Number.new(42)] Thnad::Funcall :name :args "foo" Thnad::Number :value 42 root Now, we want to transform generic Ruby data structures into purpose-built ones that we can attach bytecode-emitting behavior to.
26. class Funcall < Struct.new :name, :args def eval(context, builder) args.each { |a| a.eval(context, builder) } types = [builder.int] * (args.length + 1) builder.invokestatic \ builder.class_builder, name, types end end The bytecode for a function call is really simple in BiteScript. All functions in Thnad are static methods on a single class.
27. 3. Conditionals The first two features we’ve defined are enough to write simple programs like print(42). The next two features will let us add conditionals and custom functions.
28. 'if (0) { 42 } else { 667 }' {:cond => {:number => '0'}, :if_true => {:body => {:number => '42'}}, :if_false => {:body => {:number => '667'}}} :cond :number "0" :if_true :body :number "42" :if_false :body :number "667" root A conditional consists of the “if” keyword, followed by a body of code inside braces, then the “else” keyword, followed by another body of code in braces.
29. Thnad::Conditional :cond :if_true :if_false Thnad::Number :value 0 Thnad::Number :value 42 Thnad::Number :value 667 root Thnad::Conditional.new \ Thnad::Number.new(0), Thnad::Number.new(42), Thnad::Number.new(667) Here’s the transformed tree representing a set of custom Ruby classes.
30. class Conditional < Struct.new :cond, :if_true, :if_false def eval(context, builder) cond.eval context, builder builder.ifeq :else if_true.eval context, builder builder.goto :endif builder.label :else if_false.eval context, builder builder.label :endif end end The bytecode emitter for conditionals has a new twist. The Conditional struct points to three other Thnad nodes. It needs to eval() them at the right time to emit their bytecode in between all the zero checks and gotos.
31. 4. Function Definitions On to the final piece of Thnad: defining new functions.
32. 'function foo(x) { 5 }' {:func => {:name => 'foo'}, :params => {:param => {:name => 'x'}}, :body => {:number => '5'}} :func :name "foo" :params :param :name "x" :body :number "5" root A function definition looks a lot like a function call, but with a body attached to it.
33. Thnad::Function.new \ 'foo', [Thnad::Name.new('x')], Thnad::Number.new(5) Thnad::Function :name :params :body "foo" Thnad::Name :name "x" Thnad::Number :value 5 root Here’s the transformation we want to perform for this language feature.
34. class Function < Struct.new :name, :params, :body def eval(context, builder) param_names = [params].flatten.map(&:name) context[:params] = param_names types = [builder.int] * (param_names.count + 1) builder.public_static_method(self.name, [], *types) do |method| self.body.eval(context, method) method.ireturn end end end Since all Thnad parameters and return types are integers, emitting a function definition is really easy. We count the parameters so that we can give the JVM a correct signature. Then, we just pass a block to the public_static_method helper, a feature of BiteScript that will inspire the Rubinius work later on.
35. Compiler We’ve seen how to generate individual chunks of bytecode; how do they all get stitched together into a .class file?
36. builder = BiteScript::FileBuilder.build(@filename) do public_class classname, object do |klass| # ... klass.public_static_method 'main', [], void, string[] do |method| context = Hash.new exprs.each do |e| e.eval(context, method) end method.returnvoid end end end Here’s the core of class generation. We output a standard Java main() function...
37. builder = BiteScript::FileBuilder.build(@filename) do public_class classname, object do |klass| # ... klass.public_static_method 'main', [], void, string[] do |method| context = Hash.new exprs.each do |e| e.eval(context, method) end method.returnvoid end end end ...inside which we eval() our Thnad expressions (not counting function definitions) one by one.
38. Built-ins plus, minus, times, eq, print Thnad ships with a few basic arithmetic operations, plus a print() function. Let’s look at one of those now.
39. public_static_method 'minus', [], int, int, int do iload 0 iload 1 isub ireturn end Here’s the definition of minus(). It just pushes its two arguments onto the stack and then subtracts them. The rest of the built-ins are nearly identical to this one, so we won’t show them here.
40. II. Enter the Frenemy So that's a whirlwind tour of Thnad. Last year, I was telling someone about this project—it was either Shane Becker or Brian Ford, I think—and he said,...
41. Rubinius ...“Hey, you should port this to Rubinius!” I thought, “Hmm, why not? Sounds fun.” Let’s take a look at this other runtime that has sprung up as a rival for Thnad’s affections.
42. • As much as performance allows • Initially 100%, now around half (?) • Core in C++ / LLVM • Tons in Ruby: primitives, parser, bytecode Ruby in Ruby The goal of Rubinius is to implement Ruby in Ruby as much as performance allows. Quite a lot of functionality you’d think would need to be in C is actually in Ruby.
43. RubySpec, FFI Brought to you by Rubinius (Thank you!) We have Rubinius to thank for the executable Ruby specification that all Rubies are now judged against, and for the excellent foreign-function interface that lets you call C code in a way that’s compatible with at least four Rubies.
44. Looking Inside Your Code Rubinius also has tons of mechanisms for looking inside your code, which was very helpful when I needed to learn what bytecode I’d need to output to accomplish a particular task in Thnad.
45. class Example def add(a, b) a + b end end For example, with this class,...
46. AST $ rbx compile -S example.rb [:script, [:class, :Example, nil, [:scope, [:block, [:defn, :add, [:args, :a, :b], [:scope, [:block, [:call, [:lvar, :a], :+, [:arglist, [:lvar, :b]]]]]]]]]] ...you can get a Lisp-like representation of the syntax tree,...
47. Bytecode $ rbx compile -B example.rb ... ================= :add ================= Arguments: 2 required, 2 total Locals: 2: a, b Stack size: 4 Lines to IP: 2: -1..-1, 3: 0..6 0000: push_local 0 # a 0002: push_local 1 # b 0004: meta_send_op_plus :+ 0006: ret ---------------------------------------- ...or a dump of the actual bytecode for the Rubinius VM.
48. “Ruby Platform Throwdown” Moderated by Dr Nic, 2011 vimeo/26773441 For more on the similarities and differences between Rubinius and JRuby, see the throwdown video moderated by Dr Nic.
49. III: Thnad’s Revenge Now that we’ve gotten to know Rubinius a little...
50. Let’s port Thnad to Rubinius! ...let’s see what it would take to port Thnad to it.
51. Our Guide Through the Wilderness @brixen photo: JSConf US Brian Ford was a huge help during this effort, answering tons of my “How do I...?” questions in an awesome Socratic way (“Let’s take a look at the Generator class source code....”)
52. Same parser Same AST transformation Different bytecode (But similar bytecode ideas) Because the Thnad syntax is unchanged, we can reuse the parser and syntax transformation. All we need to change is the bytecode output. And even that’s not drastically different.
53. Thnad’s Four Features, Revisited Let’s go back through Thnad’s four features in the context of Rubinius.
54. 1. Names and Numbers First, function parameters and integers.
55. # Numbers: ldc 42 # Names: iload 0 # Numbers: push 42 # Names: push_local 0 JVM RBX See how similar the JVM and Rubinius bytecode is for these basic features?
56. class Number < Struct.new :value def eval(context, builder) builder.push value end end All we had to change was the name of the opcode both for numbers...
57. class Name < Struct.new :name def eval(context, builder) param_names = context[:params] || [] position = param_names.index(name) raise "Unknown parameter #{name}" unless position builder.push_local position end end ...and for parameter names.
58. 2. Function Calls Function calls were similarly easy.
59. ldc 42 ldc 1 invokestatic #2; //Method //add:(II)I push_const :Example push 42 push 1 send_stack #<CM>, 2 JVM RBX In Rubinius, there are no truly static methods. We are calling the method on a Ruby object— namely, an entire Ruby class. So we have to push the name of that class onto the stack first. The other big difference is that in Rubinius, we don’t just push the method name onto the stack—we push a reference to the compiled code itself. Fortunately, there’s a helper method to make this look more Bitescript-like.
60. class Funcall < Struct.new :name, :args def eval(context, builder) builder.push_const :Thnad args.each { |a| a.eval(context, builder) } builder.allow_private builder.send name.to_sym, args.length end end Here’s how that difference affects the bytecode. Notice the allow_private() call? I’m not sure exactly why we need this. It may be an “onion in the varnish,” a reference to a story by Primo Levi in _The Periodic Table_.
61. flickr/black-and-white-prints/1366095561 flickr/ianfuller/76775606 In the story, the workers at a varnish factory wondered why the recipe called for an onion. They couldn’t work out chemically why it would be needed, but it had always been one of the ingredients. It turned out that it was just a crude old-school thermometer: when the onion sizzled, the varnish was ready.
62. 3. Conditionals On to conditionals.
63. 0: iconst_0 1: ifeq 9 4: bipush 42 6: goto 12 9: sipush 667 12: ... 37: push 0 38: push 0 39: send :== 41: goto_if_false 47 43: push 42 45: goto 49 47: push 667 49: ... JVM RBX Here, the JVM directly supports an “if equal to zero” opcode, whereas in Rubinius we have to explicitly compare the item on the stack with zero.
64. class Conditional < Struct.new :cond, :if_true, :if_false def eval(context, builder) else_label = builder.new_label endif_label = builder.new_label cond.eval context, builder builder.push 0 builder.send :==, 1 builder.goto_if_true else_label if_true.eval context, builder builder.goto endif_label else_label.set! if_false.eval context, builder endif_label.set! end end Labels are also a little different in Rubinius, too; here’s what the bytecode for conditionals looks like now.
65. 4. Function Definitions The trickiest part to implement was function calls.
66. public int add(int, int); iload_1 iload_2 iadd ireturn push_rubinius push :add push #<CM> push_scope push_self push_const :Thnad send :attach_method, 4 JVM RBX Remember that in Ruby, there’s no compile-time representation of a class. So rather than emitting a class definition, we emit code that creates a class at runtime.
67. class Function < Struct.new :name, :params, :body def eval(context, builder) param_names = [params].flatten.map(&:name) context[:params] = param_names # create a new Rubinius::Generator builder.begin_method name.to_sym, params.count self.body.eval(context, builder.current_method) builder.current_method.ret builder.end_method end end The code to define a method in Rubinius requires spinning up a completely separate bytecode generator. I stuck all this hairy logic in a set of helpers to make it more BiteScript- like.
68. class Rubinius::Generator def end_method # ... cm = @inner.package Rubinius::CompiledMethod push_rubinius push_literal inner.name push_literal cm push_scope push_const :Thnad send :attach_method, 4 pop end end Here’s the most interesting part of those helpers. After the function definition is compiled, we push it onto the stack and tell Rubinius to attach it to our class.
69. Compiler How does the compiled code make its way into a .rbc file?
70. g = Rubinius::Generator.new # ... context = Hash.new exprs.each do |e| e.eval(context, g) end # ... As with JRuby, we create a bytecode generation object, then evaluate all the Thnad statements into it.
71. main = g.package Rubinius::CompiledMethod Rubinius::CompiledFile.dump \ main, @outname, Rubinius::Signature, 18 Finally, we tell Rubinius to marshal the compiled code to a .rbc file.
72. Runner (new!) That means we now need a small script to unmarshal that compiled code and run it. This is new; on the Java runtime, we already have a runner: the java binary.
73. #!/usr/bin/env rbx -rubygems (puts("Usage: #{} BINARY"); exit) if ARGV.empty? loader = Rubinius::CodeLoader.new(ARGV.first) method = loader.load_compiled_file( ARGV.first, Rubinius::Signature, 18) result = Rubinius.run_script(method) Here’s the entirety of the code to load and run a compiled Rubinius file.
74. Built-ins As we’ve just seen, defining a function in Rubinius takes a lot of steps, even with helper functions to abstract away some of the hairiness.
75. g.begin_method :minus, 2 g.current_method.push_local 0 g.current_method.push_local 1 g.current_method.send :-, 1 g.current_method.ret g.end_method For example, here’s the built-in minus() function. I wanted to avoid writing a bunch of these.
76. function plus(a, b) { minus(a, minus(0, b)) } I realized that you could write plus() in Thnad instead, defining it in terms of minus.
77. function times(a, b) { if (eq(b, 0)) { 0 } else { plus(a, times(a, minus(b, 1))) } } If you don’t care about bounds checking, you can also do times()...
78. function eq(a, b) { if (minus(a, b)) { 0 } else { 1 } } ...and if()!
79. stdthnadlib?!? We have a standard library! That means we have a standard library! Doing the Rubinius implementation helped me improve the JRuby version. I was able to go back and rip out most of the built-in functions from that implementation.
80. Thnad Online github/undees/thnad/tree/master github/undees/thnad/tree/rbx Here’s where you can download and play with either implementation.
81. This has been a fantastic conference. Thank you to our hosts...
82. Special Thanks Kaspar Schiess for Parslet Charles Nutter for BiteScript Ryan Davis and Aja Hammerly for Graph Brian Ford for guidance Our tireless conference organizers! ...and to the makers of JRuby, Rubinius, Parslet, BiteScript, and everything else that made this project possible. Cheers!