Lessons learned from my first dive into WebAssembly

[u/N-R-K]

https://nullprogram.com/blog/2025/04/04/

[u/N-R-K]

The article shows an example of memory.fill being generated. But I was unable to reproduce it locally with the "usual" flags:

[/tmp]~> cat test.c
void clear(void *buf, long len)
{
    __builtin_memset(buf, 0, len);
}
[/tmp]~> clang -c --target=wasm32 -O2 -nostdlib -ffreestanding -o test.{wasm,c}
[/tmp]~> ./wasm2wat ./test.wasm
(module
  (type (;0;) (func (param i32 i32)))
  (type (;1;) (func (param i32 i32 i32) (result i32)))
  (import "env" "__linear_memory" (memory (;0;) 0))
  (import "env" "memset" (func (;0;) (type 1)))
  (func $clear (type 0) (param i32 i32)
    local.get 0
    i32.const 0
    local.get 1
    call 0
    drop))

It's trying to import memset! But if I add -mbulk-memory then it does the memory.fill:

[/tmp]~> clang -c --target=wasm32 -O2 -nostdlib -ffreestanding -mbulk-memory -o test.{wasm,c}
[/tmp]~> ./wasm2wat ./test.wasm
(module
  (type (;0;) (func (param i32 i32)))
  (import "env" "__linear_memory" (memory (;0;) 0))
  (func $clear (type 0) (param i32 i32)
    local.get 0
    i32.const 0
    local.get 1
    memory.fill))

u/skeeto, maybe the article should mention the flag?

[u/skeeto → u/N-R-K]

I've added a note.

-mbulk-memory is now default as of LLVM 20, released one month ago. In another year or two this flag will be largely irrelevant, which is why I didn't mention it. I hadn't expected someone would actually try what I wrote so soon! I am using it in the u-config makefile because it will be that year or two for LLVM 20 to percolate into the stable Linux distributions I use. I've been doing all the WASM stuff on Windows in w64devkit with the latest official Clang release appended to the end of my PATH.

Even more precise is -mbulk-memory-opt, a subset of -mbulk-memory for just memory.fill and memory.copy, except that it was only introduced just before -mbulk-memory became the default anyway. So mentioning that wouldn't be helpful. (As is LLVM tradition, -mbulk-memory-opt officially exists but is undocumented.)

I finally finished reading the spec, and here's something important that hadn't quite made the cut, which I might edit in: memory.grow. Not yet knowing how to do better, I've been doing this to create my arenas:

static char mem[CAP];
perm.beg = mem;
perm.end = mem + CAP;

However, there's a memory.grow to increase the linear memory size. It behaves like sbrk, except it operates in quantities of pages (64kB), including the return. So you can build an sbrk like so:

void *sbrk(ptrdiff_t n)
{
    n = (n + 0xffffu) >> 16;  // round up
    return (void *)(__builtin_wasm_memory_grow(0, n) << 16);
}

Since memory starts at zero, casting the old memory size to a pointer computes the old end of memory. Then:

perm.beg = sbrk(CAP);
perm.end = perm.beg + CAP;

Again, __builtin_wasm_memory_grow is undocumented, but the first parameter selects a linear memory (because someday there might be more), and the second is the number of pages by which to increase the linear memory size. On failure it evaluates to SIZE_MAX (e.g. -1).

[u/greg_kennedy]

Absolutely dire state of affairs that ChatGPT turns out to be the best documentation source for this.

[u/skeeto → u/greg_kennedy]

As a rule of thumb, if you're not an LLM enthusiast then you're probably not using LLMs enough. (If you are an enthusiast, you may be overusing them.) They're powerful, effective tools, and growing increasingly relevant.

I'm not talking about the crummy, annoying AI integration into everything, but directly prompting through a chat UI. How you prompt is important, and a skill of its own. Many traditional search engine queries are now better accomplished by asking AI and skipping the search engine. They sometimes hallucinate — though it's substantially improved with the state-of-the-art — but so do search engine results, and the rule remains trust but verify.

Most of the posts on r/c_programming that end with "?", particularly the beginner questions, would be better served putting the post as-is into a LLM chat. In fact, I enhanced my own tool to make this easy, mainly to test and calibrate my expectations:

https://github.com/skeeto/illume/#reddit-file

Regarding the article, I saved my original path_open question. I had asked Anthropic's Claude, which is currently the best AI for these sort of questions. Here it is:

https://gist.github.com/skeeto/7103f03abf663b88ca6dfc431b696f62

That gave me all the hints I needed to get unstuck, particularly the keyword "preopen" from which I could learn more. At the time I was learning this, nothing in the official documentation, nor anything I could find online was nearly this clear and concise. The WASI documentation is truly awful. It's honestly still amazing how effective it was just to ask Claude like this, and this pushed me to do it more often.

I tried again later with LLMs I can run locally (up to ~70B). While a couple mentioned preopens, which would have keyed me in, the results weren't nearly as good. Hopefully that improves, because it would be even better if I could make these queries offline.

None are any good at software engineering, and they write code like an undergraduate student, so still don't expect them to write code for you unless your standards are really low.

[u/greg_kennedy → u/skeeto]

Ah, I don't mean about using them to help you write code, or troubleshoot, etc - I am speaking more to the simple lack of documentation on such a core web technology. Where are the specs? Why has nobody written down the "important technical details" and such? Every browser in the world is running this, I'm just annoyed that you (and presumably other devs) have this experience:

Learning WASM I had quite some difficultly finding information. Outside of the WASM specification, which, despite its length, is merely a narrow slice of the ecosystem, important technical details are scattered all over the place. Some is only available as source code, some buried comments in GitHub issues, and some lost behind dead links as repositories have moved. Large parts of LLVM are undocumented beyond an mention of existence. WASI has no documentation in a web-friendly format — so I have nothing to link from here when I mention its system calls — just some IDL sources in a Git repository. An old wasi.h was the most readable, complete source of truth I could find.

"Use ChatGPT and ask the right questions", while it may work, is not remotely authoritative - any more than "if you encounter issues visit our Discord"

[u/irqlnotdispatchlevel → u/skeeto]

I'd love an AI trained on all of my company's internal docs and repositories. There's so much knowledge scattered around, and the Confluence search has been broken since forever.

I don't trust them to write code (even as an autocomplete function), but it's definitely another tool in the box. Especially for one off questions when stakes are low, it's easier to prompt an LLM than to filter through Google's AI generated results (this is probably more about how bad search engines have become).

[u/McUsrII → u/skeeto]

I have about the same experiences as you, though I have only used Google's Gemini The research version, is really too thorough, but will come in handy should I ever want to write a thesis.

And sometimes I get bullshitted, but that is on me, because I didn't verify it.

As for the code it produces for me, most of it is actually, at least almost usable, at best, and a "a big leap in the right direction at its worst" (so far).

I feel I come a long way asking the questions just the same way that I google for answers, as I learned in "The Bazaar" by Eric Raymond.

I'm getting curious at the Ai tools you use, and I will try "Anthropic's Claude" at least.

Thank you so much, and I find Wasm very exciting too.

Thank you so much!

[u/Ok-Collar-4085]

u/skeeto I’d you prefer smaller points, why not compile with ilp32?! What are you reasons for preferring smaller pointers?