Since September @vouillon has continued extending and improving wasm_of_ocaml:
Our loops included all the code that follows, and the V8 engine used jump offsets to estimate the cost of a loop. So, it could widely overestimate the cost of loops at toplevel and produce optimised top-level code which is run only once. Since this code can be very large, this could take several minutes. Now, the code which is not involved in a loop is moved after the loop if it exceeds a size threshold.
In addition, @vouillon also contributed with a couple of broader Wasm community improvements:
Finally, he prepared and gave two presentations about wasm_of_ocaml:
This biggest blocker is that none of the stand-alone “no-JS” engines support the WasmGC extension that both wasocaml and wasm_of_ocaml rely on, AFAIK.
There’s a (slightly out-of-date) extension overview available at Roadmap - WebAssembly.
If someone is aware of WasmGC progress in other such engines, please share!
With a compilation from Ocaml to WebAssembly, and other existing compilers from C to WebAssembly, would this mean we could run in the browser OCaml programs relying on some external C libraries?
Thanks to recent changes in clang, I can tell it will be possible with Wasocaml without requiring any change (or almost no change ). We will provide alternative headers of the native FFI where current macros will be replaced by hand-written Wasm. The only limitation to expect is that Field won’t be usable as an l-value anymore. We’ll provide a Set_field one or equivalent.
Out of curiosity, is providing a Set_field (distinguishing direct assignment to a field from Store_field/caml_modify) because wasocaml benefits from this distinction, or just because it allows the C code to be more easily shared between wasocaml and the native C runtime?
I have not tried it but it should indeed be possible to link the code generated by Wasm_of_ocaml with a C library compiled to Wasm. You still need to write stubs to convert between OCaml values and C values.
As @zapashcanon is saying, with LLVM 17, it should be possible to reuse existing stubs written in C with minimal changes by compiling them with an alternative set of macros. We probably need some small changes in Wasm_of_ocaml as well for this to work, since LLVM only supports the reference type externref but we are using type (ref eq) for OCaml values, so some conversions have to be performed when calling the C stub functions.
@dra27 Field accesses have to be implemented by function calls, And there is no way to define a macro so that Field(x,n)=e is rewritten into set_field(x,n,e).
If the block has not been initialized yet, it is not safe to use Store_field. When the block has been allocated with caml_alloc_small, one currently needs to perform direct assignments Field(v, n) = v. If the block has been allocated with caml_alloc_shr, one currently needs to use caml_initialize. One needs an alternative to this function as well.
@dra27 Yes, it would make a lot of change to upstream these macros for compatibility.