Roadmap for asm.js support in emscripten

[dschuff]

Now that all the browser vendors (and Node LTS) have shipped wasm, the number of systems that developers will want to target that do not support it will rapidly get smaller. Today, most new emscripten development focuses on wasm, and most projects that use emscripten also want to target wasm [citation needed]. We are close to replacing fastcomp/asm2wasm with the upstream wasm backend as the default way to generate wasm code (#5488).
Once this happens, we will have several opportunities. Well, I call them "opportunities" for the emscripten developers because we can stop maintaining a lot of code and considerably simplify what remains. But there is of course a cost for developers that still want to target asm.js, so we should take it into account.
We should consider what level of support we want to give non-wasm use cases (which would include asm.js and "almost asm"/plain-JS) and for how long.

I think there are a couple of options in this space. I think we do eventually want to drop asm.js support from the mainline development branch of emscripten. This would allow removal of fastcomp, and a lot of code paths in emscripten that go with the asm2wasm pipeline. It would make emscripten much simpler and would especially help serving the goal of smaller JS module glue that we are discussing in #5794. It would also allow us to update the style of JavaScript code we use in emscripten, since modern wasm-supporting engines have good ES6+ language support and performance.

If we do this sooner rather than later, we could think of it more as a fork and maintain a branch of emscripten with asm.js support, where we could make bug fixes and accept patches from contributors who have specific use cases for targeting older engines.

The primary question is when this would happen, and if we want to have intermediate milestones where we keep asm2wasm or asm.js support even while developing features that won't benefit those users.

I think we should think of things in terms of requirements: i.e. what are our requirements/blockers for removing asm2wasm, and for asm.js? (browser install penetration? developers asking for support? missing emscripten features?) What are current use cases for those? (identical language or Module support for both targets? sharing JS glue?)

It's early to be talking about this, but we should be talking about it early, so we can get plenty of feedback.

[binji]

It would be interesting if wasm2asm could help here. I'm not certain of its status, but if we had this as a fallback for exceptional cases it would likely make removing the asm.js backend more viable.

[kripken]

wasm2asm could help, yeah, but it would depend on key features like the emterpreter working on wasm2asm output, which is probably not trivial. But, that could be worth doing if wasm threads don't arrive soon enough to make the emterpreter not necessary.

[floooh]

Please don't drop asm.js support too early. I think it will be important as fallback for quite a while, and it's good to have a 'second opinion' for testing wasm performance and correctness, and to be somewhat safe against regression bugs.

A few things I stumbled over:

• there are still new mobile phones sold in shops which don't support WASM out of the box, often these are phones which use their own browsers around old Chromium snapshots
• browsers other than Chrome or Firefox are much slower to respond to error reports (mostly because releases are synced with operating system updates, and because of their poor issue tracking systems which don't allow collaboration on the issues), for instance Microsoft Edge's WASM implementation triggers a bug on my emulator for quite a while now (http://floooh.github.io/virtualkc/)

Cheers!

[kripken]

I agree @floooh , we'll likely support asm.js for many years for those reasons. Hopefully we can minimize the support burden by using wasm2asm or other things, but if that has a limited featureset then it might not be enough by itself.

[dschuff]

Yeah I think having a good wasm2asm will go a long way toward simplifying emscripten without much cost in terms of capabilities that emscripten users get. I do think though that for use cases like "edge's wasm is buggy" that wasm->wasm workarounds might make more sense than falling all the way back to asm.js.

[jakirkham]

Yeah I think having a good wasm2asm will go a long way toward simplifying emscripten without much cost in terms of capabilities that emscripten users get.

It seems like these days (thanks to Binaryen) that wasm-dis + wasm2asm is enough to make this happen. Though IDK if I'm missing something here.

[kripken]

@jakirkham there is a lot more work that would need to be done there. One one side, wasm2asm is missing a bunch of wasm features, and also does not emit very efficient code yet. On the other side, we have features in emscripten that are not yet supported without the asm.js backend, like the emterpreter, so wasm2asm wouldn't be enough anyhow.

I think we can get there, but there's a lot more to do.

[gnzlbg]

We just updated Rust's emscripten backend and noticed that the asmjs and the old wasm32 targets require an LLVM 6 fork, while the new wasm32-experimental-emscripten uses a more recent LLVM.

Is there a time frame for the LLVM6 targets to be updated to a more recent LLVM ?

[kripken]

@gnzlbg I don't think anyone is currently working on undating fastcomp's LLVM/clang. But if someone were interested that would be great of course.

I think most of our focus in emscripten is on the upstream wasm backend at this point, as it is getting close to be a suitable replacement for the fastcomp path. We'll still support asm.js for a long time, though (but things like updating LLVM in fastcomp will not be a high priority).

For rust, I'd guess it may also make sense to focus on the upstream wasm32 target for your emscripten support, parallel to the non-emscripten wasm32 support. But that does leave the issue of asm.js support open, though.

[hummeleBop]

KaiOS, the mobile platform system, cannot launch WebAssembly applications.
KaiOS will be more relevant the next several years, I think the asm.js backend is still useful.

[sbc100]

Does KaiOS specifically optimize for asm.js? Or would the wasm2js be just as good?

[hummeleBop]

KaiOS is aware of asm.js subset optimizations..
This mobile platform is really low-spec and 'almost asm' is probably not enough here.

[sbc100]

What JS engine does KaiOS use?

I think its unlikely that we are going to keep fastcomp/asm.js support in the long term. If there are users such as KaiOS for which wasm2js is not good enough it may be that pinning to fixed release of emscripten is that only way to go. Hopefully we can make wasm2js good enough for everyone though.

[hummeleBop]

KaiOS is obviously a fork of the good old B2G (Boot to Gecko) and it uses SpiderMonkey, but the source https://github.com/kaiostech/gecko-b2g is based on Gecko 48.

[sbc100]

Can we reach a conclusion here?

It seems like once we drop fastcomp support from mainline emscripten then we will for sure loose pure asm.js support. That leaves KaiOS with two choices:

1. Find some way to update to more recent SpiderMonkey that has wasm support
2. Pin emscripten to the last know version that includes fastcomp.
3. ??

It seems like (2) is the most rational choice. What do other think?

[sbc100]

Also I should ask @hummeleBop, are you still in the same state today.. being stuck on Gecko 48?

[kripken]

cc @fabricedesre for KaiOS status

[fabricedesre]

Current KaiOS devices are still on Gecko 48, yes. This will change but I can't comment on the timeline.

[kripken]

Thanks @fabricedesre !

Then option 2 that @sbc100 mentioned sounds best in the meantime (to use an emscripten version that has asm.js support, which currently means using fastcomp instead of the default upstream, and after fastcomp is removed will also mean to use an older version).

[sbc100]

OK I'm gonna close this out for now since it sounds like we have a plan