Conversation
|
It looks like this PR removed a (partial) wasm2c implementation of the Emscripten ABI, is that correct? Is this available elsewhere? |
|
@turbolent I'm not aware of implementations elsewhere. Do you have a use case for it, I'm curious? |
|
@kripken Though there is quite some software ported to WebAssembly and WASI, it seems like there is even more software ported to Emscripten. Though Emscripten has a primary focus on allowing software to get ported to the Web/browser, it could also be really useful for porting software in general. So I'm looking into adding support for Emscripten to https://github.com/turbolent/w2c2, which is very similar to wasm2c |
|
Ideally Emscripten would mostly use WASI where possible, see PR / comment #18285 (comment) |
|
I see, thanks @turbolent . Yeah, adding more WASI support in Emscripten makes sense, and we've tried to do that as much as we can, but WASI APIs are not complete/compatible enough for all the things needed on the Web, so there is some unavoidable fragmentation here, unfortunately. In a perfect world server VMs would support Web APIs or Web VMs would support WASI, but there seems little interest on either side, and valid reasons for them not to, at this point in time. Note that Emscripten does have standalone mode ( |
This was very useful for me personally in exploring the options in the wasm2c
space, and in benchmarking in particular, for:
https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html
At this time, however, all known users of wasm2c are using upstream wasm2c
from wabt directly. And the benefits of emscripten's integration are diminishing
as features like wasm-EH remove the need for emscripten-EH (which wasm2c
supported here). So we might as well remove this option to get rid of the
complexity, since this is already quite behind upstream wasm2c, and the work
to update it is not trival, and not worth it given the lack of users.