deps: update wasm3

[saghul]

No description provided.

[ggcrunchy]

Hi. I mentioned over here that I was going to play with QuickJS-NG for a bit. As it happens, I was also using WASM3 (after some early difficulties with WAMR) and aware of this project as well.

Anyhow, I'm aiming at loading WASM-based plugins from Lua, with a first stress test being libopenmpt, whose "web" version uses non-standalone Emscripten and so brings in a JS runtime (download here, and docs).

I was able to call a few "get version" functions with raw WASM3, but thanks to some files from txiki now seem able to call _malloc. 🙂

---

I've only grabbed files from the project, and not been building it wholesale, and am probably a ways from production besides, so not sure I can have a PR for a while. But I figured I'd at least point out a few relevant bits of progress:

Here is my go at the JS side of a Memory polyfill.

C-side bits of the same.

(I haven't tested grow().)

Further up are the JS side of imports.

(I'm embedding as source to avoid the intermediate build step, and it seems fine for this small use case.)

And C-side.

My idea to handle imports was to add an intermediate WASM function (with an open signature) whose userdata is an index. The corresponding Javascript functions to be called are stored in an array and looked up via this index, and called according to the import signature.

There were a few new APIs since the version you currently use, but I forgot what changed and how much I'm using. (I believe globals and tables got some provisional support, too.)

I'm loading them with these two functions, along with some other stuff lower down.

Adding an empty object under the library key (in this case "libopenmpt") and then adding the WASM binary under the "wasmBinary" key, along with the previous bits, seem to be enough to get to _malloc, at least. Will see if more remains. 😄 (Although at this point I'll probably also see about making some Lua <-> JS bridges to allow for more widespread use. Will need to work out error-handling and object lifetimes among the three (!!!) runtimes, etc.)

(N.B. I am very green when it comes to Javascript, so I wouldn't be surprised if there are issues. I might also further adapt wasm.c to fit my VM-inside-Lua setup.)

EDIT: There were indeed issues! 😄(I also realized, while adding tables, that I unwittingly implemented something like them for imports.) Anyhow, with various fixes and a (non-cryptographic) crypto.getRandomValues() polyfill, I also got loading from memory working, which apparently made a few JS <-> WASM transitions. Those changes probably stomped most if not all of the links, but anyhow I only really wanted to make the existence of this stuff known.

EDIT 2: Regarding the "globals ... got some provisional support", if you manually give them a name you can look them up. 🙂 From what I can tell there's no such information in the data you parse, so probably the API really just wanted an index.

[ggcrunchy]

@saghul (Probably should have done that earlier.)

I turned on DUMP_LEAKS and had some further work to do. 😄 But the last one to track down, that had me almost pulling out my hair, was this bit when I had no return values (JS_Call()ing the _free() from the Emscripten runtime), since it was leaving an array behind. Maybe it's considered bad practice to ignore return values, I guess, but in case it's not I figured I'd bring it up. 🙂

Anyhow, this is now playing music well. 😄

[saghul]

Sorry for the delay!

Good to see my code was useful beyond this proyect 😅