report.md

What is done

• Wasm interpreter in Hoon
  • used to actually run WebAssembly in the Mars side of the urwasm stack
  • replaced by wasm3 Wasm runtime in C in the jet
• Lia language specification and interpreting suite
  • Language for Invoking Assembly (Lia) is a higher level DSL used to script WebAssembly binaries (modules) and to provide FFI and I/O capabilities to Wasm modules with imports
  • The goal of Lia development is to define an interpreting function that would take a Wasm binary, Lia script and some other parameters, and produce an output, and then jet this function. That way the inner state of the Wasm runtime is not exposed (avoids overhead of copying Wasm runtime state on each invocation), and there's no conversion between the representations of Wasm runtime state in Hoon and in C (no need for bespoke interpreters, Hoon code is not coupled to a particular Wasm runtime in C, no overhead of converting between the representations)
  • When some piece of code is compiled to Wasm, it is actually compiled to Wasm and JS. The latter defines higher-level wrappers to script the former and provides interface for Wasm imports. The browser always has direct access to the state of Wasm runtime, e.g. memory buffer. In urwasm Lia plays role of JS, and it has direct access to the Wasm runtime state, which is encapsulated in ++lia-main gate call. This gate is jetted with a Lia runtime implementation in C, which calls to wasm3 instead of the Wasm runtime in Hoon.
  • Lia interpreting suite consists of Lia-to-Wasm compiler and a runtime gate.
  • Lia runtime provides arbitrary FFI and I/O to Wasm. Examples: importing a Hoon interpreting function in Rust String -> String that returns a pretty-printed result of the expression.
• ++lia-main jet prototype
  • The interpeting function itself is quite small, under 500 lines of code. It has dependencies of course such as Wasm runtime and Lia-to-Wasm compiler, but these can be simply called from the jet. So the jet simply reproduces the same logic as the original code in Hoon, except it calls wasm3 instead of my Wasm interpreter.
  • The jet misses some key elements like linking of the provided modules (the original module and the module compiled from a Lia script). But I an already evaluate numerical functions in it, i.e. it works as long as I'm doing simple arithmetics with it.

What is being worked on

• ++lia-main jet
  • Most of the time is being spent on figuring out wasm3 API to link modules. Once it's done, the prototype will be almost fully functional like the original ++lia-main gate, except for a few wrinkles discussed below.

What's next

• Allocating on the loom. wasm3 requires patching to use Vere allocator instead of its own, otherwise it'll leak memory
• Ensuring determinism:
  • softfloat calls instead of whatever wasm3 is using for floating point arithmetics
  • limiting my Wasm interpreter in Hoon/switching to a newer release of wasm3/switching to another runtime (my interpreter allows global variable imports but wasm3 doesn't AFAIK)
  • Wasm and Lia code validation
  • some other details like determenism of memory.grow
• Caching/persistent memoization of ++lia-main
  • Interactions with Wasm runtime in Lia is performed by rerunning the entire script. That means O(n^2) time complexity of Wasm calls and O(n) instantiation overhead, where n is the number of interactions i.e. FFI calls from Wasm and consecutive function invocations from a Wasm module with persisiting state.
  • Saving jet state in between Arvo events will bring the asymptotics back to sane scalings.
• Lia text format. Right now the script is written in AST noun format, which is very cumbersome.

Projected timelines

I cannot give any time estimates until late August, since right now I am focused on my doctoral dissertation. I hope that I make the imports work by Summit to show some demos.

What would be possible

Whatever is possible with Wasm+JS stack should be possible with Lia, taking into account loom size limitations. Spider threads/Gall agents in Wasm would be possible, although long-running agents would require caching to be performant.