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 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.
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.
It’s been a while since I published the last chapter of LazyVim for Ambitious Developers on the website, but I was waiting for the print edition to be available to share it widely. And that required waiting (twice) for proofs to be mailed to me.
But it’s finally here! For a direct link to purchase the print edition, click here.
I’m proud of the book contents. I’m pretty confident that even seasoned Vim power users would pick up one or two tricks they didn’t already know.
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.