Tracking issue for wasm2asm

[tlively]

Work that needs to be done before wasm2asm can be used in toolchains or as a polyfill:

• finish i64 to i32 lowering pass
• finish wasm2asm translation of ops
• implement wast assertion translations for i64s
• full spec tests for wasm2asm
• performance testing wasm backend -> wasm2asm vs Fastcomp
• performance parity with Fastcomp

Work to be done once wasm2asm is finished:

• integrate wasm2asm into Emscripten
• phase out Fastcomp in favor of wasm backend -> wasm2asm

[xtuc]

I'm currently working on https://github.com/xtuc/js-webassembly-interpreter. I think that a client side interpreter would be more efficient since you can take advantage of the WASM format and It also allows you to switch to native if supported/needed.

I'm planning to use asm.js in the interpreter to have better performance.

[tlively]

Oh neat, I filed this as an intern! wasm2js has been stable for a long time now and Emscripten now uses it when compiling to JS, so this is all done.