the allowed set of wasm features is not clear

[yamt]

when working on #749, i wondered what wasm features are allowed to be used by carts.
however, i couldn't find documentation stating it.

for example, bulk-memory instructions are used by some of carts out there.
otoh, C Makefile provided by w4 doesn't enable it.

i guess it's "whatever wasm3 support"?

[yamt]

related: #679

[JerwuQu]

My proposal is to support the WASM 1.0 specification with bulk-memory extensions.

Passive data segments (part of the bulk-memory spec) are especially useful for WASM-4 when having data that is only loaded sometimes, for example game levels or soundtracks. This avoids it taking up precious working-memory when the data isn't needed. I've personally had to work around this using a preprocessor to generate literals in code that initialize memory sections on demand, but this is very space-inefficient for the same purpose.

The problem with defining the bulk-memory spec as supported is that wasm3 doesn't support all bulk-memory features yet, and the ability to load passive memory is one still missing last I checked. The wasm3 development has mostly stagnated due to the still ongoing war, and I feel like we can't completely standardize the WASM-4 supported feature-set before there's a strategy for both the web and native runtimes to support it.

Some ideas:

• Officially "support what wasm3 supports" for both web and native. Feels a bit strange to me since it's in theory a moving target, but it's pretty much what we have right now like you said.
• Instead of wasm3 for the main WASM-4 native runtime, use another WASM runtime that supports the whole bulk-memory proposal and is also portable to all the weird platforms that libretro supports. Could either be a wasm3 fork, or something like your toywasm. How much have you experimented with porting toywasm? See https://git.libretro.com/libretro/wasm4/-/blob/main/.gitlab-ci.yml for the libretro build configuration.
• Limit strictly to the WASM 1.0 spec. Would soft-break a ton of games that only use basic bulk-memory operations.
• Accept that some games will only work on the web runtime and not the main native runtime. Very sad for the native runtimes!

Regardless of what we go with, it would be nice to tie it into #491 to make sure all published games actually follow it. There could of course be exceptions (for things like WasmGC), but that those games are then marked as outside of WASM-4 specification.

[yamt]

My proposal is to support the WASM 1.0 specification with bulk-memory extensions.

Passive data segments (part of the bulk-memory spec) are especially useful for WASM-4 when having data that is only loaded sometimes, for example game levels or soundtracks. This avoids it taking up precious working-memory when the data isn't needed. I've personally had to work around this using a preprocessor to generate literals in code that initialize memory sections on demand, but this is very space-inefficient for the same purpose.

i was thinking about something similar for my carts. but i quickly gave up because it seemed difficult/impossible with wasm-ld. maybe viable for some other languages though.

The problem with defining the bulk-memory spec as supported is that wasm3 doesn't support all bulk-memory features yet, and the ability to load passive memory is one still missing last I checked. The wasm3 development has mostly stagnated due to the still ongoing war, and I feel like we can't completely standardize the WASM-4 supported feature-set before there's a strategy for both the web and native runtimes to support it.

the latest llvm has something called bulk-memory-opt.
https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md#bulk-memory-opt
i guess wasm 1.0 + bulk-memory-opt covers what many of wasm4 carts need.

* Instead of wasm3 for the main WASM-4 native runtime, use another WASM runtime that supports the whole bulk-memory proposal and is also portable to all the weird platforms that libretro supports. Could either be a wasm3 fork, or something like your toywasm. How much have you experimented with porting toywasm? See https://git.libretro.com/libretro/wasm4/-/blob/main/.gitlab-ci.yml for the libretro build configuration.

wasm4 ci builds libretro artifacts with toywasm as well.
except that, i haven't used or tested libretro by myself.

anyway, as toywasm is generally slower than wasm3, i suspect it isn't a great replacement for the purpose of wasm4.
https://github.com/yamt/toywasm?tab=readme-ov-file#how-slowfast-is-this

Regardless of what we go with, it would be nice to tie it into #491 to make sure all published games actually follow it. There could of course be exceptions (for things like WasmGC), but that those games are then marked as outside of WASM-4 specification.

i agree.