remixlabs/wasicaml

Translate OCaml bytecode to WebAssembly

wasicaml's Issues

can wasmtime+wasicaml run the wasm spec interpreter?

The problem could be that it needs the emulated exceptions for running. But we could also be just lucky.

reject that Gc.set changes the stack limit

as we cannot reallocate the stack

a call graph would be useful

i.e. we'd like to know the information that a directly called function f1 calls another function f2.

The Wc_tracefuncs analysis could exploit this for the transitive closure over the called functions.

node: bad option: --experimental-wasm-bigint

Building wasicaml fails on node v16.4.0 with the above error. Probably this option has been made the default, since removing it from bin-template/wasi_run allows us to compile and use wasicaml just fine.

figure out noalloc C calls

Extension of #7

optimized small functions that can be directly called

As an extension of #2:

A second function definition is provided for small functions that can be directly called. This second definition passes one OCaml arg per Wasm arg:

function letrecX_direct(i32 envptr, i32 param1, i32 param2, ...) : i32

This shall only be done if:

• there are no allocations
• the number of args is small
• the size of the function body is small
• no incompatible features like APPLY and APPTERM

Also, note that fp is unavailable. So nothing can be stored on the stack. Because there are no allocations, all intermediate values can be put into local variables.

need bootstrap test

e.g.

• compile ocamlc with wasicaml to wasm
• use this version of ocamlc to compile wasicaml
• check whether files are identical

reject when the bits for encoding the subfunction number overflow

Currently there are 10 bits for the subfunction number. Throw an error when we have more then 2^10 subfunctions.

improve APPLY

The complete stack is straightened right now but this is not necessary.

translate a couple of C calls to direct code

Extension of #5 - not only float/int32/64/nativeint artithmetic.

In particular:

• float comparison
• string access with out of bounds check
• array access with out of bounds check
• float array access
• Bigarray.Array1 access with and without out of bounds check

wasm tail calls

Tail calls are already specified but not yet widely available. Nevertheless, we can run experiments with them and make them optional -enable-tail-calls.

In particular, the startover hack can then be removed.

unboxing for float/int32/int64/nativeint

Sort of straight-forward,... but there is a difficulty. Most values are finally converted to OCaml values, and this means that some memory needs to be allocated. In particular, this affects straighten_stack, and there can now be allocations during that procedure.

Another option is to do the allocation at the original place, but to skip it when it is not needed.

integrated assembler

Instead of using the clang assembler we could also write the binary wasm code directly.

pass the first arg of an OCaml function via wasm parameter

• the functions have then 5 wasm params
• it is the task of the callee to reserve stack space for the new param (so that we can store arg0 in fp[0])
• this can be in particular exploited by Wc_apply_direct

optimized int representation

Currently most operations return RIntVal but they can process either RInt or RIntVal.

For an optimized representation we need to know the users of a value. During the liveness pass #6 we could also gather information about the best representation of ints.

support reraise

to keep the exception backtraces more accurate

direct calls: figure out when the envptr can be omitted

Many smaller functions do not access the environment, and thus it is not needed to pass a real address as envptr parameter to these functions.

Analysis: must be recursive - e.g. a function does not access the environment because there are only direct calls that do not need the environment, ...

generate wasm exceptions

The spec is in the final round, so why not try it out?

improve exceptions

maybe it is better to return a 0 in order to signal an exception? This would avoid the JS-based throw function.

We cannot, however, avoid the JS-based try function because the exception could also be thrown by a C function, and we still need to catch that.

factor restart code out (if tail calls are available)

If Wasm tail calls are available, we can factor out the RESTART code into a separate function that finally does a return_call to the function for the non-restart case.

Also, the code pointer shifting is no longer needed (saves some instructions).

enable the method cache

it is already implemented and we just need to assign a memory cell for each cache

find directly callable functions

In wasm, direct calls are cheaper than indirect calls. Also, direct calls can be inlined.

The idea is to scan the code for instruction sequences like:

• create closure with empty environment
• put the closure into an array
• optionally, the array is put into further arrays
• finally, the outermost array is put into a global
• there must not be further instructions that set the global
• also, the arrays are only accessed with "getfield" (i.e. read-only)

exception handling: generate throw and rethrow instructions directly

Currently there is an indirection via wasicaml_wrapthrow, and OCaml functions even tend to return exceptions via a NULL pointer. Better:

• do not return NULL pointers, and use a throw instruction instead
• use rethrow if possible

Also, look at how we can interpret stack traces from JS.

remove the `rename` host function - use WASI instead

does a value need to be stored on the stack?

Extension of #6:

When we know the liveness range of a store, we can also check whether there is the chance of a GC in that range. If not, values can be stored in local variables, which is generally cheaper.

liveness analysis of stores in Wc_unstack

It would be useful to know when a stored value falls out of use, in particular for branching. Right now it is tried to make the stores equal when there are several jumps to the same label. Often, this is needless work.

Calling OCaml from JS fails with indirect call to null

I've prepared a minimal demo at https://github.com/copy/wasicaml-demo/tree/js_to_ocaml. It fails in Firefox with "RuntimeError: indirect call to null" and in Chromium with "RuntimeError: function signature mismatch".

The C call works (i.e., this line gets printed: https://github.com/copy/wasicaml-demo/blob/js_to_ocaml/stubs.c#L12). The assertion below also doesn't fail, so the issue is likely in caml_callback.

disable that the stack size can be changed at runtime

this is caml_change_max_stack_size

or comment it out in caml_gc_set

recognize recursion and use direct call

A self call of the same "let rec" can be recognized by the Koffsetclosure instruction that precedes Kapply.

A direct call is a bit cheaper than an indirect call (no wasm function type check).

support Printexc.get_backtrace

Currently, you can get backtraces from JS only.

reduce code size in initialization functions (letrec_main)

We already prevent local variables from being allocated and write all values to the stack. More is possible:

• Shorter allocation snippets: instead of alloc_fast/alloc_slow just use caml_alloc_small
• Shorter initialization of blocks: e.g. blockinit3(value, offset, p1, p2, p3) to write three values at value[offset], value[offset+1] and value[offset+2] (will need such functions for e.g. n=1 to n=5, and also shr versions that base on caml_initialize)
• Shorter function calls

add a linking mode so that the `system` host function is disabled

for full WASI compatibility

better no_function analysis

e.g. for min and max we could deduce this:

let min x y = if x < y then x else y

Because a function cannot be compared, we can follow that neither x nor y is a function.

Not sure why this cannot be concluded yet...

pass all OCaml args via Wasm params if possible

This is only advantageous when a function is called directly, and when tail calls are available.

We need to generate two wasm functions:

• one that complies to the usual conventions where the args are passed on the stack
• one that expects all args in Wasm params

The former function would do grab and restart, and call the other function.

--prefix is not respected

It seems that ~/.wasicaml is still baked in somewhere at runtime. --prefix does install into the given directory, but tools still search in ~/.wasicaml:

% PATH=/tmp/prefix/bin:$PATH wasicaml a.out -o test
* parsing...
  number instructions: 2560
  number labels: 210
* creating CFG...
  number nodes: 266
* linearize...
  number functions: 111
* validating...
* translating to WASM...
* print as .wat...
* print as .s (llvm integrated assembler syntax)...
* assemble...
+ /home/fabian/.wasicaml/bin/wasi_cc -o 'a.out.o' -c 'a.out.s'
/bin/sh: line 1: /home/fabian/.wasicaml/bin/wasi_cc: No such file or directory
SYSTEM:  /home/fabian/.wasicaml/bin/wasi_cc -o 'a.out.o' -c 'a.out.s'
Error: Command failed: /home/fabian/.wasicaml/bin/wasi_cc -o 'a.out.o' -c 'a.out.s'
    at checkExecSyncError (node:child_process:826:11)
    at execSync (node:child_process:900:15)
    at /tmp/prefix/js/main.js:68:13
    at <anonymous>:wasm-function[476]:0x1f403
    at <anonymous>:wasm-function[151]:0xe63c
    at wasicaml_call (<anonymous>:wasm-function[28]:0x3488)
    at /tmp/prefix/js/main.js:23:38
    at wasicaml_wraptry (<anonymous>:wasm-function[26]:0x3448)
    at <anonymous>:wasm-function[150]:0xc9da
    at _start (<anonymous>:wasm-function[25]:0x32fd) {
  status: 127,
  signal: null,
  output: [ null, null, null ],
  pid: 56512,
  stdout: null,
  stderr: null
}
command failed

A symbolic link from ~/.wasicaml to the prefix directory temporarily fixes the issue.

get constants from C

in particular

• domain_field_<name>
• <name>_tag