WAMR integration & WASM/WASI compilers

[KaruroChori]

Or the real Path of Pain with even less rewards at the end.

The integration of WAMR should enable vs:

• To download distributed toolchains for arbitrary languages supporting wasm as target, and run them in pipelines.
  For example, a C compiler running in WAMR and generating a wasm output.
• To run embedded scripts in one of the languages for which a toolchain is available, or to run pre-compiled wasm files.
• To run native components compiled for wasm, not really for safety in this case but for portability.
  To the extreme of this, running the full app in vs after XML->C->wasm

All this is technically feasible, and would be more or less as complex as the other integration have been so far.
The only exception would be running native components, for which it is unclear the scope of the exposed interface:

• Either we provide cfltk bindings, allowing real custom widgets to be defined and used, while wrapping them as ui_base objects
• Providing access only to the same APIs needed by the XML builder, which are based on prepacked widgets without directly interfacing with fltk.
• Both of them.

Subtasks:

• Integrate an engine (WAMR)
• Find a way to have llvm/clang running as wasm an build to wasm (no emscripten) spoiler, not working
• Find a way to integrate assemblyscript as a language and embeding the compiler ahah. not even close

However...

Issues with WASM

Why is WASM so frustrating to work with!?! Virtually no compiler can compile itself into a functional wasm/wasi binary.
I am starting to regret the portability of java bytecode already. I never considered this day would have come.

AssemblyScript is barely able to do so with some magic tricks, but it still requires binaryen distributed alongside. Because of that, V8 is virtually the only runtime capable of running that combo.

There are also some LLVM patches to support wasm/wasi, but they all have been failures so far (at best half working). Aside from the fact it would end up being quite slow.

Notice: the wasmer registry seems to have a small collection of clang builds on it. It might be good enough to start experimenting.

If you have insights to share, please do that because I am really out of ideas.

[andy5995]

Not wanting to cause you any more pain, but I'll tell you that I don't have experience with anything you mentioned above. My friend @Jammyjamjamman might wanna have a glance and see if he's interested though.

[KaruroChori]

No worries, those attempts were made few weeks ago, long enough for me to heal :D.

[KaruroChori]

For my ref: https://github.com/appcypher/awesome-wasm-langs

[KaruroChori]

More refs on how to integrate native functionality in the wasm runtime:
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/export_native_api.md
https://github.com/bytecodealliance/wasm-micro-runtime/tree/main/samples/native-lib

The main issue would be offering them for fltk via cfltk.
Codegen is the only option to keep it sane, and it is unclear if the entire interface can be trivially represented within the restrictions of wasm and if not how to handle that.

For now, building bindings to vs and its public widgets is far more simple (mostly because we can write the vast majority of that as part of the current codegen pipeline)

Integration of bindings for embedded scripts is just as complex as the one for quickjs, so at least that part is ok.

[KaruroChori]

Integrating wasm would have been nice, but it really looks like:

• tooling is bad for compilers not running on v8
• the standardization process a landmine field
• intrinsic dumb design decisions like not supporting arbitrary jumps, preventing things like QBE and many standalone compilers to target it.

I have been looking for alternatives, and this might be a good one: https://github.com/libriscv/libriscv
Small, lightweight, embeddable and sandboxed. Even better, virtually everything can target riscv and can run on riscv.... so I guess WASM goes in the freezer for a while as I test if this option is more feasible.