The current interpreter is very simple:

• It doesn't pre-compute anything.
• It executes directly from flash.

It is thus an in-place (non-optimized) interpreter according to A fast in-place interpreter for WebAssembly by Ben L. Titzer.

We would like to give users control over the tradeoff between performance and footprint (both in flash and memory). The following improvements would go towards this direction:

• Implement the optimizations discussed in the paper above, and feature-gate those that don't improve both performance and footprint (like the sidetable).
• Implement optimizations similar to what wasm3 does, by translating the opcodes into their function addresses, and feature-gate them.
• Implement a feature to persist in flash the translated code in the optimization above. This optimization means that a platform update would invalidate the applet (unless the original bytecode is preserved). Such translated code wouldn't need validation and translation when starting and may execute directly.
• JIT and AOT are probably out of the question for now. If wasmtime or wasmer end up supporting no-std, the situation might simplify. The difficulty being that they would need to run in a different thread to not take control of the scheduler thread. See Explore Wasmtime as an alternative WebAssembly runtime #458
• Use Pulley which principles and rationale seem to fit very well to our use-case.

Open questions:

• Does it make sense to have a feature like toctou which would remove all dead panics? (not just those with a corresponding dynamic check, but all where the compiler doesn't prove it on its own)
• How to benchmark? Which suite to use?
• If there's a way to detect hot/cold functions and optimizations have a cost per function, only hot functions may be optimized.

Related work:

• https://github.com/Neopallium/s1vm aims to be a Rust port of Wasm3, but didn't get any activity since 2 years.

The work is tracked in the dev/fast-interp branch.