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.
Data section 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.
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.
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.
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 part 8 left off, as we try to expand the parser to something more than an empty WAT (module).
Reminder: You are reading content that took a great deal of effort to craft, compose, and debug.
In earlier articles, we implemented a tokenizer for the Wasm text syntax (WAT) and started on a parser to convert those tokes to a S-expression AST.
In this part, we’ll start to create a transformer to convert that AST to a new one that better matches the WASM output we will be crafting. Don’t ask me how many parts that’s going to take!
Reminder: You are reading content that took a great deal of effort to craft, compose, and debug.
In earlier articles, we implemented a tokenizer for the Wasm text syntax (WAT). In part 6, we started building a parser. We ended that part on a bit of a down note when I realized we were in for yet another refactor. I’m in a better mood today and it’s looking like it won’t be so bad, after all!
Reminder: You are reading content that took a great deal of effort to craft, compose, and debug.