I know from experience that if I use a laptop keyboard for any length of time, I will be forced to do voice coding for months while the RSI heals.
Therefore I don’t own a laptop. For the past five years this has meant I’m chained to my desk if I want to do any coding or computing (though a tablet and pencil have been my go-to for non-typing tasks such as easy web browsing).
I spent most of my winter break in my wood shop, working on some tech adjacent projects that I will post about later. However, I also spent a fair amount of time at my keyboard, working on a handful of gleam projects I wanted to introduce here.
I’m theoretically working on a small full stack application, but as so often happens with me, I was sidetracked by developing open source libraries that I have no hope of keeping maintained. So these projects are all in support of full stack web development on lustre and wisp.
I love coding. I love writing. I love writing about coding, as evidenced by the archives of this blog and the multiple tech books I have written.
I’ve always prided myself on being able to explain things clearly. I have a unique ability to identify the order in which to teach concepts. I have enough five star reviews on my books to know that there are plenty of readers out there who agree with me.
In earlier articles, we have implemented a tokenizer, parser, and transformer to convert WAT syntax to a Wasm AST, and got started on the code generation.
In this part, we’ll finally wrap up code generation and be able
to compile our hello world sample into something that wasmtime
can run.
I hope.
In earlier articles, we have implemented a tokenizer, parser, and transformer to convert WAT syntax to a Wasm AST, and got a good portion of the code generation step in place.
Unless there are any unexpected detours, this part will cover more code generation and take us through a messy refactor that Roc helpfully makes not so messy!
In earlier articles, we have implemented a tokenizer, parser, and transformer to convert WAT syntax to a Wasm AST and got started on the code generation.
This part will continue with code generation. We’ll start with the import section because it has a couple interesting complications that we need to take into account.
Consider this wat import statement:
(module
(import "wasi_snapshot_preview1" "fd_write" (
func $fd_write (param i32 i32 i32 i32) (result i32))
)
)
If we look at the bytes in the binary representation of this section, it’s surprisingly long:
In earlier articles, we have implemented a tokenizer, parser, and transformer to convert WAT syntax to a Wasm AST, and started building a code generator to create bytes from that AST. The structure of the code generator is in place already, so our remaining task is to generate all the other sections of our input module.
The next section I want to implement is the data section, which is described in the Wasm spec here.
In earlier articles, we have implemented a tokenizer, parser, and transformer to convert the Web Assembly Text Format to an Abstract Syntax Tree that can hopefully easily compile to Wasm.
Truthfully, the next step should be validation. Validation is the process of statically analyzing the syntax tree to catch as many errors as possible. This is where things like type checking and borrow checking happen, for example.
The wasm spec has an in-depth description of what validation should look like for a conforming compiler. But we are not building a Wasm-conforming compiler. We’re barely even building a Wasm-looking compiler! The truth is, static analysis gets its own university class and textbook, distinct from the complier classes and textbooks, so I think we can be forgiven for skipping it.
In earlier articles, we implemented a tokenizer and parser to convert Wasm’s WAT syntax into an S-expression abstract syntax tree and started to implement a transformer to convert that AST into one more suitable for generating Wasm bytecode.
This article continues where we left off, building the last piece of the transformer. This piece needs to represent arbitrary instructions inside a function body, so it’s going to take a bit of massaging. But we’ll get there!
In earlier articles, we implemented a tokenizer and parser to convert Wasm’s WAT syntax into an S-expression abstract syntax tree and started to implement a transformer to convert that AST into one more suitable for generating Wasm bytecode.
Now that the boilerplate is in place, this article will continue to implement recursive transformer functions, getting into some of the more complicated expressions in the “hello world” WAT example.
I should mention that the code in this article gets long and repetitive. I’m including all the code we’ll need for the hello world example, but if you feel like it’s getting a bit boring, feel free to skim bits of it! I now understand why most “introduction to compiler” articles focus on such a tiny amount of syntax! I feel committed now, though, so if you’re willing to bear with me, we’ll see this through to the end.
