Overengineered calculator: Zig + QBE

2026-07-29T00:00:00+00:00

For many who want to understand how compilers work, Crafting Interpreters</a> by Robert Nystrom and Writing An Interpreter In Go</a> (plus Writing A Compiler In Go</a>) by Thorsten Ball are the go-to resources. I worked through both of them. I learned how tokenization works, what language grammars and EBNF</a> notation are about. I built my first recursive descent parser</a> and then brought the code to life by interpreting it directly (slow) and by implementing a bytecode compiler and a virtual machine (faster).

What these two books didn't teach me was how to translate source code to native machine code. Enter: QBE</a>.

QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code. QBE fosters language innovation by offering a compact user-friendly and performant backend. The size limit constrains QBE to focus on the essential and prevents embarking on a never-ending path of diminishing returns. </blockquote>
I came up with a small project demonstrating how to go through all the steps necessary to transform source code into a native executable. Inventing yet another programming language would have been counterproductive. I would have spent my time fighting design decisions instead of focusing on what was important for me: code generation.
Arithmetic expressions were an obvious and simple problem to solve. But how to turn 2 + 2 * 2</code> into 6</code> instead of 8</code>? I started by defining a grammar. The grammar told me what tokens I should expect and how to handle precedence rules. For example: multiplication and division should be performed before addition and subtraction.
I ended up with this:
Expression = Sum;
Sum = Product , { ( "+" | "-" ) , Product };
Product = Unary , { ( "*" | "/" ) , Unary };
Unary = ( ( "-" | "+" ) , Unary ) | Primary;
Primary = Number | "(" , Expression , ")";</code></pre>
What does it mean?


the tokens are: numbers, operators (+</code>, -</code>, *</code>, /</code>) and parentheses to group expressions
</li>

the precedence rules result from following the grammar rules top to bottom, from the loosest one to the tightest one:

Expression</code> is a Sum</code> (addition and subtraction)</li>
Sum</code> is a list of Product</code> (multiplication and division)</li>
Product</code> is a list of Unary</code> (negation)</li>
Unary</code> is either Primary</code> or, when there is an operator, another Unary</code></li>
Unary</code> operations can be stacked: ----1</code> = 1</code></li>
Primary</code> is either a Number</code> or a grouped Expression</code></li>
</ul>
</li>
</ul>
Tokenizer</h2>
Based on the grammar, I implemented a tokenizer in Zig</a>.
I took inspiration from a real Zig tokenizer</a>.
With a list of token tags:
pub const Tag = enum {
 invalid,
 eof,

 left_paren,
 right_paren,

 plus,
 minus,
 star,
 slash,

 number,
};</code></pre>
Note: invalid</code> and eof</code> are meta tags to know when to stop, either on invalid token or end of input.
The tokenizer became a simple state machine:
const TokenizerState = enum {
 start,
 number,
};

pub fn nextToken(self: *Tokenizer) Token {
 var result: Token = .{ .tag = .eof, .start = self.current_position, .end = undefined };

 state: switch (TokenizerState.start) {
 .start => switch (self.input[self.current_position]) {
 0 => {},
 ' ', '\t', '\n', '\r' => {
 self.current_position += 1;
 result.start = self.current_position;

 continue :state .start;
 },
 '0'...'9' => {
 result.tag = .number;
 self.current_position += 1;

 continue :state .number;
 },
 '+' => {
 result.tag = .plus;
 self.current_position += 1;
 },
 '-' => {
 result.tag = .minus;
 self.current_position += 1;
 },
 '*' => {
 result.tag = .star;
 self.current_position += 1;
 },
 '/' => {
 result.tag = .slash;
 self.current_position += 1;
 },
 '(' => {
 result.tag = .left_paren;
 self.current_position += 1;
 },
 ')' => {
 result.tag = .right_paren;
 self.current_position += 1;
 },
 else => {
 result.tag = .invalid;
 self.current_position += 1;
 },
 },
 .number => switch (self.input[self.current_position]) {
 '0'...'9' => {
 self.current_position += 1;

 continue :state .number;
 },
 else => {},
 },
 }
 result.end = self.current_position;

 return result;
}</code></pre>
(see: full source code</a>).
Parser</h2>
Then, I created a parser to build the Abstract Syntax Tree from the list of tokens.
The Sum</code>, Product</code> and Unary</code> from the grammar became binary</code> and unary</code> operations:
const BinaryOp = enum {
 add,
 sub,
 mul,
 div,
};

const UnaryOp = enum {
 neg,
};

pub const AstNode = union(enum) {
 binary: struct {
 lhs: *AstNode,
 op: BinaryOp,
 rhs: *AstNode,
 },
 unary: struct {
 op: UnaryOp,
 rhs: *AstNode,
 },
 number: i64,
};</code></pre>
(see: full source code</a>).
Interpreter</h2>
After reading the books, interpreting the AST directly was straightforward:
pub const Interpreter = struct {
 pub fn interpret(ast: Ast) !i64 {
 return eval(ast.root);
 }

 fn eval(node: *const AstNode) !i64 {
 return switch (node.*) {
 .binary => |b| switch (b.op) {
 .add => try eval(b.lhs) + try eval(b.rhs),
 .sub => try eval(b.lhs) - try eval(b.rhs),
 .mul => try eval(b.lhs) * try eval(b.rhs),
 .div => try std.math.divTrunc(i64, try eval(b.lhs), try eval(b.rhs)),
 },
 .unary => |b| switch (b.op) {
 .neg => -try eval(b.rhs),
 },
 .number => |value| value,
 };
 }
};</code></pre>
(see: full source code</a>).
Emitter</h2>
It was time for the fun part. First, I built a QBE intermediate language code emitter.
The official documentation</a> was an invaluable resource.
My add</code>, sub</code>, mul</code>, div</code> and neg</code> operations mapped directly to QBE instructions:
# add 64-bit 2 to 2 and store the result in a temporary %result
%result =l add 2, 2</code></pre>
Same applied to all other instructions.
In QBE, the intermediate language is in static single-assignment form</a>.
That meant I needed to emit a QBE instruction for all my binary</code> and unary</code> operations and stack them together. There was no point
in emitting an instruction for, for example, +4</code> as it was the same as 4</code>.
For a 2 + 2 * 2</code> expression that was:
# ld means: as long integer
data $fmt = { b "%ld\n", b 0 }
export function w $main() {
@start
 %.0 =l mul 2, 2
 %.1 =l add 2, %.0
 # call C printf function, needs linking with libc, to print the result
 call $printf(l $fmt, ..., l %.1)
 ret 0
}</code></pre>
For -2 + 2 * (4 / 2)</code> that was:
data $fmt = { b "%ld\n", b 0 }
export function w $main() {
@start
 %.0 =l neg 2
 %.1 =l div 4, 2
 %.2 =l mul 2, %.1
 %.3 =l add %.0, %.2
 call $printf(l $fmt, ..., l %.3)
 ret 0
}</code></pre>
(see: full source code</a>).
Compiler</h2>
The last piece needed was tying everything together and generating a native executable.
I decided to divide the compiler into three stages:


Qbe</code>:

tokenizing</li>
parsing</li>
emitting QBE SSA</li>
using qbe</code> executable to produce a raw assembly file</li>
</ul>
</li>

Cc</code>: compiling the assembly into an executable. Since I implemented everything in Zig,
it was natural to just invoke zig cc</code>
</li>

Run</code>: running the executable and outputting the result.
</li>
</ul>
From start to finish it was just:
$ oc "2 + 2 * 2"
6</code></pre>
I decided to leave all build artifacts for manual inspection.
target/result.ssa</code> contains the QBE IL:
data $fmt = { b "%ld\n", b 0 }
export function w $main() {
@start
 %.0 =l mul 2, 2
 %.1 =l add 2, %.0
 call $printf(l $fmt, ..., l %.1)
 ret 0
}</code></pre>
target/result.s</code> contains the assembly generated by qbe -o result.s result.ssa</code>:
.data
.balign 8
fmt:
 .ascii "%ld\n"
 .byte 0
/* end data */

.text
.balign 16
.globl main
main:
 endbr64
 pushq %rbp
 movq %rsp, %rbp
 movl $6, %esi
 leaq fmt(%rip), %rdi
 movl $0, %eax
 callq printf
 movl $0, %eax
 leave
 ret
.type main, @function
.size main, .-main
/* end function main */

.section .note.GNU-stack,"",@progbits</code></pre>
There was one interesting thing I have observed. As QBE is an optimizing compiler backend,
it folded all the constants and returned the result directly: movl $6, %esi</code>.
With division present (-2 + 2 * (4 / 2)</code>), it didn't happen, though:
.data
.balign 8
fmt:
 .ascii "%ld\n"
 .byte 0
/* end data */

.text
.balign 16
.globl main
main:
 endbr64
 pushq %rbp
 movq %rsp, %rbp
 movl $2, %ecx
 movl $4, %eax
 cqto
 idivq %rcx
 imulq $2, %rax, %rax
 movq %rax, %rsi
 addq $-2, %rsi
 leaq fmt(%rip), %rdi
 movl $0, %eax
 callq printf
 movl $0, %eax
 leave
 ret
.type main, @function
.size main, .-main
/* end function main */

.section .note.GNU-stack,"",@progbits</code></pre>Closing thoughts</h2>
The full source code is available here</a>. qbe</code> and zig</code> packages are needed to build and run it.
On Alpine Linux it's as easy as:
$ apk add qbe zig</code></pre>
The project is in a fairly complete state. It may be rough around the edges: more tests would be nice and better error handling,
especially around overflows and division by 0.

Clojure + deps.edn, a basic guide

2019-07-05T00:00:00+00:00

After a rather long break from programming and Clojure I decided give them another go. When it comes to managing Clojure projects, Leiningen</a> is de-facto standard tool. Recently, Clojure CLI tools</a> are becoming more and more popular, though. Switching to yet-another-build-tool doesn't have any pragmatic value, but it's perfect for learning purposes.

From a build tool I expect it to perform certain tasks:

Creating a project.</li>

Managing source and tests paths.</li>

Managing dependencies.</li>

Running tests.</li>

Building a self-contained JAR, a.k.a. uberjar.</li>

Managing outdated dependencies.</li> </ol>
Let's see how it's performed using Clojure CLI tools, a.k.a. deps.edn.
Creating a project</h3>
Leiningen allows to generate a project structure simply by invoking:
$ lein new [template] [project-name]</code></pre> We get a lot for free, but is it really needed? How is it done with Clojure CLI tools? Imagine a simple project. It allows add and divide numbers, it also prints some example calculations when invoked. We can start by simply creating a new directory:
$ mkdir cdeps && cd cdeps</code></pre> Now, let's add an empty deps.edn</code> file:
;; /deps.edn {}</code></pre> And now we can start adding some actual code to the project.
Managing source and tests paths</h3>
To demonstrate the feature of managing source paths we will put our code at src/main/clojure</code>.
$ mkdir -p src/main/clojure</code></pre> deps.edn</code> is no magic so we can just set the path in the file:
;; deps.edn {:paths ["src/main/clojure"]}</code></pre> Now, we can write the calculator code: ;; src/main/clojure/com/tomekw/cdeps/calculator.clj (ns com.tomekw.cdeps.calculator) (defn plus [a b] (+ a b)) (defn divide [a b] (/ a b))</code></pre>Managing dependencies</h3> In such a simple project there is no real need to add external dependencies. We can always specify the Clojure version we would like to use, though: ;; deps.edn {:paths ["src/main/clojure"] :deps {org.clojure/clojure {:mvn/version "1.10.1"}}}</code></pre> Clojure CLI tools allow to specify local and git dependencies too, see documentation and more examples</a>. Running tests</h3> The calculator we wrote is super simple but we can still write some tests: ;; test/main/clojure/com/tomekw/cdeps/calculator_test.clj (ns com.tomekw.cdeps.calculator-test (:require [clojure.test :refer :all] [com.tomekw.cdeps.calculator :refer :all])) (deftest adding-numbers (is (= 4 (plus 2 2)))) (deftest dividing-numbers (is (= 2 (divide 4 2)))) (deftest dividing-numbers-by-zero (is (thrown? ArithmeticException (divide 1 0))))</code></pre> Now we need to run them to make sure they pass. We have to add an alias (a command we will run), and a test runner, as an extra dependency. I picked kaocha</a>. Also, we need to tell the runner where the tests are located: ;; deps.edn {:paths ["src/main/clojure"] :deps {org.clojure/clojure {:mvn/version "1.10.1"}} :aliases {:test {:extra-paths ["test/main/clojure"] :extra-deps {lambdaisland/kaocha {:mvn/version "0.0-529"}} :main-opts ["-m" "kaocha.runner"]}}}</code></pre> Here is the test report: $ clj -Atest [(...)] 3 tests, 3 assertions, 0 failures.</code></pre>Building a self-contained JAT, a.k.a. uberjar</h3> Presume, we would like to print example calculations to the console. Let's add the code to do that: ;; src/main/clojure/com/tomekw/cdeps/core.clj (ns com.tomekw.cdeps.core (:gen-class) (:require [com.tomekw.cdeps.calculator :refer :all])) (defn -main [& args] (do (println (format "2 + 2 is %s" (plus 2 2))) (println (format "4 / 2 is %s" (divide 4 2)))))</code></pre> To run the main function we can invoke the following command: $ clj -m com.tomekw.cdeps.core 2 + 2 is 4 4 / 2 is 2</code></pre> It could be burdensome for the users of our calculator to install Clojure. To avoid this, we can package our project as a standalone Java JAR. There is number of tools to do that, like cambada</a>, but I've decided to try out uberdeps</a>. Let's add a proper configuration first: ;; deps.edn {:paths ["src/main/clojure"] :deps {org.clojure/clojure {:mvn/version "1.10.1"}} :aliases {:test {:extra-paths ["test/main/clojure"] :extra-deps {lambdaisland/kaocha {:mvn/version "0.0-529"}} :main-opts ["-m" "kaocha.runner"]} :uberjar {:extra-deps {uberdeps {:mvn/version "0.1.4"}} :main-opts ["-m" "uberdeps.uberjar" "--target" "target/cdeps-0.1.0.jar"]}}}</code></pre> To package the project we simply run: $ clj -Auberjar [uberdeps] Packaging target/cdeps-0.1.0.jar... + src/main/clojure/** + org.clojure/clojure 1.10.1 . org.clojure/core.specs.alpha 0.2.44 . org.clojure/spec.alpha 0.2.176 [uberdeps] Packaged target/cdeps-0.1.0.jar in 567 ms</code></pre> And now we can run the project with Java: $ java -cp target/cdeps-0.1.0.jar clojure.main -m com.tomekw.cdeps.core 2 + 2 is 4 4 / 2 is 2</code></pre>Managing outdated dependencies</h3> It's often needed to manage the versions of all dependencies we put into our deps.edn</code> file. There is a tool named depot</a>: ;; deps.edn {:paths ["src/main/clojure"] :deps {org.clojure/clojure {:mvn/version "1.10.1"}} :aliases {:test {:extra-paths ["test/main/clojure"] :extra-deps {lambdaisland/kaocha {:mvn/version "0.0-529"}} :main-opts ["-m" "kaocha.runner"]} :outdated {:extra-deps {olical/depot {:mvn/version "1.8.4"}} :main-opts ["-m" "depot.outdated.main" "-a" "outdated"]} :uberjar {:extra-deps {uberdeps {:mvn/version "0.1.4"}} :main-opts ["-m" "uberdeps.uberjar" "--target" "target/cdeps-0.1.0.jar"]}}}</code></pre> Everything should be up to date: $ clj -Aoutdated All up to date!</code></pre>Summary</h3> This guide covers basic use-cases in the daily workflow with Clojure. Of course there is always more than I presented here, like deploying the project to Clojars</a>. The process is still not fully automated and I will try to cover it with the next post. The source code for this post can be found here</a>.

Simple blockchain in Ada

2018-06-20T00:00:00+00:00

I consider myself a late adopter. Everyone talks about blockchain these days. Everyone tries to apply the technology everywhere, even when it does't make sense. So let's learn by doing and try to implement the simple blockchain from scratch. And let's do this in Ada!

Wikipedia defines blockchain as:

The programming language I want (part 1)

2018-06-19T00:00:00+00:00

As a software engineer and as a business-oriented person I always try to be pragmatic. That’s why I think both Ruby and Rails are still, in 2018, a great choice to start a new project. In the end, the choice of the technology doesn’t matter (unless you’re in a special kind of niche) — it’s all about delivering and creating a business value.

It doesn’t stop me, though, from experimenting with other technologies, looking for the next big thing, or just for the new concepts to bring to my daily Ruby toolbox. I’ve played with the number of programming languages: Ada, Clojure, Scala, Go, Elixir, and Rust, to name a few. Thanks to this I was able to compile the list of features that impressed me the most, not to mention my programming techniques have improved dramatically.

The programming language I want but doesn’t exist yet would be statically-typed. Ada, Scala, and Rust showed me all the advantages of programming with types. To simplify, these annotations are invaluable when designing interfaces and even deriving implementation from the type signatures! Also, I must stress I don’t think types are a replacement for tests.

One of the pain points I had with Scala was the myriad of options to model one thing. That’s where Go shines: maybe it sometimes feel too simple but forces the developer to express the code in one way. In my opinion that’s a great advantage when working in teams on bigger projects.

Another thing I disliked when programming in Scala was abuse of syntax shortcuts and cryptic operators. More verbose and readable language like Ada spoke to me more.

Clojure showed me how important and useful immutability is. It greatly affected my style of designing data structures and manipulations around them.

I don’t believe in the orthodox approach to functional programming (I’m looking at you, Haskell). At the same time, most of us will agree there is no coming back when you try pattern matching and higher-order functions. This will and should leave a trace about how you structure your object-oriented code and mix it with these functional concepts.

As a long time Vim and now Emacs user I never got used to IDEs. I understand they are certainly useful but I don’t like to be forced to anything.

REPL has always been the one of the most significant parts of my daily workflow. I can’t imagine writing code without the experiment phase first or the debugging session in the console later on. It’s a shame one of my newest toys, Rust, doesn’t support it (yet).

This brings me to the question: what’s the language I should name as the most wanted by me. After giving it some thought I would pick… Rust. More pragmatic than Ada, more strict than Clojure, a better Scala (?), a smarter Go, and just a statically-typed Elixir, high-level enough to meet my general-purpose programming needs.

Disclaimer: I believe all the languages mentioned here are great. The purpose of this post is just to mention things I would like to see in my perfect language.

OCaml</h3>
The main problem with OCaml is, I believe, its adoption. It appeared 21 years ago (in 1996), yet, it didn’t get into the mainstream or just gained enough popularity. The job market is weak and limited to trading firms. Maybe that’s just common misconception and I may be mistaken.</p>

Tomek Wałkuski

Overengineered calculator: Zig + QBE

WSL2 is enough

(N)vim for Clojure development

Clojure + deps.edn, a basic guide

Simple blockchain in Ada

The programming language I want (part 2)

The programming language I want (part 1)

Unit testing ActionCable channels with RSpec

Is Ada a failed language?

Tomek Wałkuski

Overengineered calculator: Zig + QBE

Compiler</h2> The last piece needed was tying everything together and generating a native executable. I decided to divide the compiler into three stages:</p> Qbe</code>:</p>

WSL2 is enough

(N)vim for Clojure development

Clojure support</h3> To efficiently write Clojure code I needed syntax highlighting, structural editing support, REPL management, and context-aware autocomplete.</p> These three plugins:</p>

Clojure + deps.edn, a basic guide

Creating a project</h3> Leiningen allows to generate a project structure simply by invoking:</p>

Managing source and tests paths</h3> To demonstrate the feature of managing source paths we will put our code at src/main/clojure</code>.</p>

Building a self-contained JAT, a.k.a. uberjar</h3> Presume, we would like to print example calculations to the console. Let's add the code to do that:</p>

Simple blockchain in Ada

The programming language I want (part 2)

OCaml</h3> The main problem with OCaml is, I believe, its adoption. It appeared 21 years ago (in 1996), yet, it didn’t get into the mainstream or just gained enough popularity. The job market is weak and limited to trading firms. Maybe that’s just common misconception and I may be mistaken.</p>

The programming language I want (part 1)

Unit testing ActionCable channels with RSpec

Is Ada a failed language?

OCaml</h3>
The main problem with OCaml is, I believe, its adoption. It appeared 21 years ago (in 1996), yet, it didn’t get into the mainstream or just gained enough popularity. The job market is weak and limited to trading firms. Maybe that’s just common misconception and I may be mistaken.</p>