Add WASM32 Platform

[basicer]

Adds WASM32 as a new platform, allowing it provide an implementation of the wasm-c-api interpreter to applications that themselves want to be compiled to wasm.

[yamt]

what platform is your target?
eg. wasi, emscripten, ...
it's might be better to name the core/shared/platform bits accordingly.

do you have any plan for the CI?

[basicer]

I've been testing with emscripten, but targeting wasi-sdk.

[lum1n0us]

Sorry, but I don't fully understand the use case of this PR. Does it mean a wasm32-wasi version of wamr which is compiled by wasi-sdk or emscripten?

[basicer]

The idea is that for applications that use the wasm-c-api, those applications can still run in the browser by embedding WAMR as the wasm runtime, and allowing WARM to be built for the browser.

[lum1n0us]

A browser use the WASM runtime via wasm-c-api to execute wasm32-wasi or wasm32-emscripten? WAMR is still a native library for the browser.

[basicer]

Here is an example use case: ashtonmeuser/godot-wasm#78 That is a plugin for the Godot game engine that allows it to load gameplay logic written in webassembly. The game engine runs on many platforms, but also in the browser. To support running in the browser, some tweaks were needed to WAMR to add WASM32 as a platform.

[lum1n0us]

• wasm32 is a target, but the platform name should be specific, like wasi or emscripten.
• If it's not too much trouble, please create a mini product for the platform to demonstrate how it works. We can then add the corresponding steps in CI.

[lum1n0us]

IIUC WASM_ENABLE_INVOKE_NATIVE is designed to prevent the involvement of runtime built-in functions. In that case, -DWAMR_BUILD_LIBC_BUILTIN=0 -DWAMR_BUILD_LIBC_WASI=0 can achieve the same effect, along with -DWAMR_BUILD_QUICK_AOT_ENTRY=0.

[yamt]

i guess it's a good opportunity to replace the heavy ifdef conditions with something easier to maintain.

[yamt]

Here is an example use case: ashtonmeuser/godot-wasm#78 That is a plugin for the Godot game engine that allows it to load gameplay logic written in webassembly. The game engine runs on many platforms, but also in the browser. To support running in the browser, some tweaks were needed to WAMR to add WASM32 as a platform.

i'm a bit confused. the project states wasmtime and wasmer support. i don't think they (or any jit-based runtimes) can run on wasm. is the combination just currently not supported?

[basicer]

i'm a bit confused. the project states wasmtime and wasmer support. i don't think they (or any jit-based runtimes) can run on wasm. is the combination just currently not supported?

Right. Currently that plugin doesn't support the web build. I'm adding WAMR support to that project specifically because it seemed feasible to port WARM's faster interpreter to WASM.

[basicer]

• wasm32 is a target, but the platform name should be specific, like wasi or emscripten.

I generally use emscripten's toolchain but pass the -sPURE_WASI=1 option such that it generates executables that can be run on the command line with WASI hosts. What platform would you consider that?

• If it's not too much trouble, please create a mini product for the platform to demonstrate how it works. We can then add the corresponding steps in CI.

The posix mini target seems to work out of the box with WASI, I'll see about getting the build script setup for that.

[yamt]

why do you avoid using platform_wasi_types.h?

[ashtonmeuser]

• wasm32 is a target, but the platform name should be specific, like wasi or emscripten.

I generally use emscripten's toolchain but pass the -sPURE_WASI=1 option such that it generates executables that can be run on the command line with WASI hosts. What platform would you consider that?

Seems like emscripten would be the correct choice for platform here. Practically, as it applies to https://github.com/ashtonmeuser/godot-wasm, emscripten is also what Godot uses to build for the web.

Although a case could be made for WAMR to have a generic unknown platform akin to Rust's wasm32-unknown-unknown target.