3 ms·

Huh, TIL. There's no C interpreter fallback for WebAssembly in Firefox that works on all platforms?

AlbertoGP 4y ago
It seems that WebAssembly support requires the JavaScript JIT (Just-In-Time) compiler: > “Unfortunately I have not had time to do much more work on the JIT because of the holidays, family responsibilities and $DAYJOB. I won't be offended at all if someone beats me to the punch especially as I'm starting to see WebAssembly becoming a hard dependency even for some add-ons (without the JIT there is no support for wasm).” > https://www.talospace.com/2019/12/firefox-71-on-power.html https://www.talospace.com/2019/12/firefox-71-on-power.html That’s from December 2019. As of 2022-05-31, there has been some progress but it’s still not working: > “I can't figure out where the bugs are in our POWER9 Ion JavaScript JIT implementation, though I still strongly suspect it's because we use sign-extended 32-bit ints. This is enough to pass the test suite but still breaks with the web. MIPS does too and we are strongly based on the MIPS port, but one wonders if MIPS suffers from the same issues, and I'm quite sure it's not tested anywhere near as well. As 32-bit arithmetic instructions aren't orthogonal in Power ISA this change would require some significant rearchitecting and I've just come off a really bad week at work, so I'll just try to pull up the current JIT to 102 so that those of you building the new ESR can continue to use Baseline Interpreter and Baseline Compiler, and then it will be time for more major surgery on the source code. You can help (please!).” > https://www.talospace.com/2022/05/firefox-101-on-power.html https://www.talospace.com/2022/05/firefox-101-on-power.html Looks like it’s not that simple.
- buu700 4y ago
  This seems really odd to me. If it's possible to convert wasm to C[1], then it should be possible to convert wasm to asm.js and just execute that. That may not be ideal, but surely it's a better stopgap solution than letting the happy path fail for years on end. 1: https://github.com/WebAssembly/wabt/tree/main/wasm2c https://github.com/WebAssembly/wabt/tree/main/wasm2c
flohofwoe 4y ago
Emscripten can still compile to asm.js (which is a subset of Javascript), and this can be used as fallback path on ancient browsers. But without special asm.js support the performance cost will be very high. Of course the actual question is: why does a login form need to load a WASM blob.

It seems that WebAssembly support requires the JavaScript JIT (Just-In-Time) compiler: > “Unfortunately I have not had time to do much more work on the JIT because of the holidays, family responsibilities and $DAYJOB. I won't be offended at all if someone beats me to the punch especially as I'm starting to see WebAssembly becoming a hard dependency even for some add-ons (without the JIT there is no support for wasm).” > https://www.talospace.com/2019/12/firefox-71-on-power.html https://www.talospace.com/2019/12/firefox-71-on-power.html That’s from December 2019. As of 2022-05-31, there has been some progress but it’s still not working: > “I can't figure out where the bugs are in our POWER9 Ion JavaScript JIT implementation, though I still strongly suspect it's because we use sign-extended 32-bit ints. This is enough to pass the test suite but still breaks with the web. MIPS does too and we are strongly based on the MIPS port, but one wonders if MIPS suffers from the same issues, and I'm quite sure it's not tested anywhere near as well. As 32-bit arithmetic instructions aren't orthogonal in Power ISA this change would require some significant rearchitecting and I've just come off a really bad week at work, so I'll just try to pull up the current JIT to 102 so that those of you building the new ESR can continue to use Baseline Interpreter and Baseline Compiler, and then it will be time for more major surgery on the source code. You can help (please!).” > https://www.talospace.com/2022/05/firefox-101-on-power.html https://www.talospace.com/2022/05/firefox-101-on-power.html Looks like it’s not that simple.

buu700 4y ago
This seems really odd to me. If it's possible to convert wasm to C[1], then it should be possible to convert wasm to asm.js and just execute that. That may not be ideal, but surely it's a better stopgap solution than letting the happy path fail for years on end. 1: https://github.com/WebAssembly/wabt/tree/main/wasm2c https://github.com/WebAssembly/wabt/tree/main/wasm2c

flohofwoe 4y ago

Emscripten can still compile to asm.js (which is a subset of Javascript), and this can be used as fallback path on ancient browsers. But without special asm.js support the performance cost will be very high. Of course the actual question is: why does a login form need to load a WASM blob.