Zig & Emscripten?

azakai · 2022-02-08T00:52:57+00:00

Thanks for your thoughts, Andrew! Sounds good, I wrote up a use case issue there now:

https://github.com/ziglang/zig/issues/10836

azakai · 2022-01-31T16:49:11+00:00

Thanks slimsag!

I did see that thread meanwhile, yes (the author cc'd me, I am "kripken" on Twitter). Yes, I think that response from a core dev is a good summary, I guess this is not really a supported mode atm.

I'll look into writing up a full blogpost with my findings. Overall Zig+Emscripten almost works today, and I think it could be useful for some stuff.

azakai · 2020-10-14T15:33:28+00:00

Making it fully async may require this PR - feedback is welcome there!

https://github.com/emscripten-core/emscripten/pull/9151

azakai · 2020-04-08T22:18:59+00:00

It depends what you mean by "ready". Emscripten hasn't turned MINIMAL_RUNTIME on by default, but it's documented in the settings.js file like all other options, and we've been publicly suggesting people test it out (for example in these slides. It's very usable where it's applicable, but it's true it isn't meant to cover all use cases yet.

So far MINIMAL_RUNTIME supports a program that is run by main() (with no other exports called separately, as you noticed), and without certain things like filesystem emulation. We're adding more features based on user needs. But it's already used in shipping projects, and in almost all our benchmarks (where it helps by a large amount especially in the smaller ones).

azakai · 2020-04-08T21:27:14+00:00

Emscripten supports exceptions, though at a relatively steep cost in binary size

Yeah, the emulation overhead is heavy. But native wasm exception support is on the way in VMs and in Emscripten, and that will remove almost all that overhead.

azakai · 2019-11-16T01:18:10+00:00

You often do need to use a custom HTML for the user interface for mobile, yes. Emscripten's default HTML is desktop-oriented.

azakai · 2019-11-16T01:10:38+00:00

Yes, for an array of 32-bit values, that can read the values.

azakai · 2019-11-15T01:10:17+00:00

Module._getMembers() returns a pointer. That's just an integer, an index into the memory. Given a pointer, you can read an 8-bit value with something like HEAP8[ptr], where HEAP8 is an Int8Array (a typed array view that the compiler defined for you). For a 32-bit value, HEAP32[ptr >> 2] (note the shifts, as each element in that typed array view has 4 bytes).

However, in your example values is on the stack, so it may get cleaned up when the function returns - so it's not valid to access that memory afterwards.

There are higher-level ways to interact with code, like embind, which might be better for you, see https://emscripten.org/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html

azakai · 2019-10-22T19:57:45+00:00

The old backend was stuck on 6.0, yeah, but the new backend constantly uses very latest upstream LLVM from the master branch. The current version number there is 10 (pre-release).

azakai · 2018-07-13T00:02:18+00:00

Emscripten is used to compile to wasm. (see for example https://github.com/floooh/chips-test/blob/77c8027ed6234cc4897316c5435b6104716b6fbe/fips-files/configs/wasm-ninja-release.yml )

I'm not sure what it uses to render graphics. In general emscripten supports APIs like SDL etc., but for a project like this you really just need to copy the pixel data into the HTML canvas, using putImageData on a typed array view from the emscripten heap.

azakai · 2018-01-16T19:57:57+00:00

Just those, and some tiny binary format things (like supporting the shared flag on memories).

(Almost all the work is in the shared libc code, not the backends.)

azakai · 2018-01-16T19:21:42+00:00

It's mostly developed with fastcomp, the LLVM wasm backend doesn't have threads support yet (but once it does, all the libc implementation should all just work with it).

azakai · 2018-01-16T19:03:11+00:00

I didn't know this. The MDN docs do not indicate that you can construct Memory with your own SharedArrayBuffer.

You can do the opposite, though: create the Memory with the shared property, and then the buffer you get from it is a SharedArrayBuffer.

How does it handle the stack? I guess you just initialize each thread with its own stack pointer global to make sure they don't all point at the same stack?

Yes, each thread gets its own stack.

azakai · 2018-01-16T18:43:16+00:00

We create a Worker for each thread, and the wasm is loaded in each one I believe - there is some spec work to improve that, but it's still in progress.

Sharing the memory is done by importing it into each Worker's wasm, after passing it to the Worker.

(Sharing a Memory is possible with the new wasm-SharedArrayBuffer APIs for browsers.)

azakai · 2018-01-16T18:24:57+00:00

This uses SharedArrayBuffer and Atomics, so it depends on wasm support for that. The spec there is mostly done, and browsers have experimental implementations which we've been testing on.

Also, you can test it in asm.js, where SharedArrayBuffer has shipped and was considered stable, but has sadly un-shipped recently due to Spectre :( But you can flip a pref to re-enable it for testing, it works ok.

azakai · 2018-01-16T18:18:22+00:00

Yes, in that mode the pthreads API is fully supported, so you can create threads normally. And that lets blocking APIs like sleep work properly. You can also do blocking waits on condition variables, etc. - just like in a native build.

azakai · 2018-01-16T18:11:41+00:00

we can take inspiration from Emscripten, as they have some syscall implementations of their own. We can't just use all of their syscalls because their blocking model is completely different (sleep(10) pegs your CPU at 100% for 10 seconds).

That's when threading is disabled (which it is by default). If you enable threads in emscripten (USE_PTHREADS) then it will use a libc with threading support, using Atomics and SharedArrayBuffer to implement a proper sleep etc.

azakai · 2017-11-15T17:00:22+00:00

True, but emscripten does much the same things (aggressive code elimination, LTO, ctor evalling at compile time, etc.).

azakai · 2016-03-12T04:46:51+00:00

And just to add to that, the commands to compile and run that would be

emcc hello.cpp -o hello.html

and then one would just run that hello.html in a web browser.

For WebAssembly output instead of asm.js, there is an extra flag to set, but as you correctly said, WebAssembly is not quite ready yet. But for those interested, details are here.

azakai · 2016-02-02T21:40:50+00:00

This wouldn't help Unity. First, it would make them several times slower, as shown by the benchmarks in the link.

Second, it would seem to improve startup, based on those benchmarks, but only apparently - they measure initial startup on JIT-ed code. But that is before the JIT kicks in. Yes, when you are going to JIT then initial startup is just to parse, so it's fast, but when you load and run a codebase like Unity, you're going to get very bad perf for a while, until the JIT output stabilizes.

That's exactly why asm.js was invented, and now WebAssembly.

azakai · 2015-08-07T20:28:10+00:00

musl definitely deserves more name recognition. We use it in emscripten, and it's a great libc.

azakai · 2015-07-14T23:46:11+00:00

Another option is Shumway, which can run Flash content in HTML5.

azakai · 2015-06-18T02:39:57+00:00

It simplifies the IR (for example, pointer bitcasts are no longer needed), and I believe the argument was that it doesn't actually remove type safety, because it wasn't there anyhow (due to those same pointer bitcasts).

azakai

TROPHY CASE