Support for wasm target

[ringtailsoftware]

I am trying to build bytebox for a wasm-freestanding target to allow wasm plugin type code inside a wasm app. Disabling the unsupported WASI handlers isn't a problem, but the build fails as zig-stable-array does not support WASM (no virtual memory).

Is this fixable, or is virtual memory essential?

[rdunnington]

Heya, I have been thinking about this for a while actually, because I think it would be good to support targets that don't have virtual memory (like some embedded platforms). Right now, bytebox uses virtual memory mainly as an optimization to avoid memcpy overhead when resizing allocations. However, this isn't required for it to be functional. There are a few places that would need to be updated to either fall back to a traditional array or maybe a chunked array:

1. Validation control stack: ModuleValidator.control_types
2. MemoryInstance backing memory
3. StringPool backing memory

One other question: when you disabled wasi support, did you have to make source changes? Ideally there would be some sort of compile-time option that could enable or disable it so there wouldn't have to be any source changes.

[ringtailsoftware]

Yes, I made source changes to disable WASI as it seemed to be the only option.
I'm looking for a WASM VM to use in both embedded projects (ARM Cortex-M, no OS) and web game/graphics projects which themselves will be compiled to WASM-freestanding

[rdunnington]

Ok I believe with the completion of #88 you should be able to disable wasi with -Dwasi=false compile option, which IIRC should also be supported when using it as a package. The other changes will take a bit more time since I'm not super satisfied with the std's SegmentedList and will want to write a stable-address container myself.

[rdunnington]

I finished a new container that should be able to replace StableArray for most of the use-cases: https://github.com/rdunnington/zig-chunk-list
I'll be working on integrating that next.