Alon Zakai

cc @dcodeIO for the AssemblyScript repo

I'm not sure what's going wrong, but `__wasmfs_mount` is an internal method, and isn't meant to be used from user code like that. We don't have any tests for using...

@eqrion > Any web experience that requires more than 16GiB is unlikely to run for most users. I'm open to raising the limit someday, but I'm skeptical it's going be...

I've experimented with this, https://github.com/WebAssembly/binaryen/commit/8f62072fe1ae743ae607521120f2be9d5d30c712#diff-633311eb1c9f14a0358c77ab7ed93b97 It may be worth it as an option to use setjmp over exceptions for precompute, and aside from that, we just use exceptions for fatal...

Yes, those are options. Another option is to rewrite the interpreter to be stack-based, which is how wasm-traversal works.

A stack interpreter might be better, yeah. It could basically use wasm-traversal. But it would be more code, which is a downside. Is this urgent for some reason?

@MaxDesiatov I'm curious to understand your use case: is this to run on the developer's machine, or to ship with the code? And if on the developer's machine, why not...

> This is to run Swift apps (including SwiftWasm itself eventually) linked to binaryen on any Wasm host, either browsers or any other non-JS host such as Cloudflare workers. Oh,...

Re-reading this now (after seeing #3722), an option not mentioned is to add an option for a binaryen build without error handling. That is, no exceptions would be thrown on...

Actually - wasm exceptions now fully work in at least LLVM, v8, and binaryen. And maybe other VMs too? And @dschuff has verified recently that binaryen compiled with wasm exceptions...