WebAssembly (Wasm) interpreter.

Continuous Integration Test Coverage Documentation Crates.io
ci codecov docs crates

wasmi- WebAssembly (Wasm) Interpreter

wasmi was conceived as a component of parity-ethereum (ethereum-like contracts in wasm) and substrate. These projects are related to blockchain and require a high degree of correctness. The project is not trying to be be involved in any implementation of any of work-in-progress Wasm proposals. Instead the project tries to be as close as possible to the specification, therefore avoiding features that are not directly supported by the specification.

With all that said wasmi should be a good option for initial prototyping and there shouldn't be a problem migrating from wasmi to another specification compliant execution engine later on.

Developer Notes


Clone wasmi from our official repository and then build using the standard cargo procedure:

git clone https://github.com/paritytech/wasmi.git
cd wasmi
cargo build


In order to test wasmi you need to initialize and update the Git submodules using:

git submodule update --init --recursive

Alternatively you can provide --recursive flag to git clone command while cloning the repository:

git clone https://github.com/paritytech/wasmi.git ---recursive

After Git submodules have been initialized and updated you can test using:

cargo test

It is recommended to further specify --release since compiling and testing without optimizations usually is slower compared to compiling and testing with optimizations.


Supported platforms are primarily Linux, MacOS, Windows and WebAssembly.

Use the following command in order to produce a WebAssembly build:

cargo build --no-default-features --target wasm32-unknown-unknown


On 64-bit platforms we further provide cross-platform suppport for virtual memory usage. For this build wasmi using:

cargo build --features virtual_memory


In order to benchmark wasmi use the following command:

cargo bench --manifest-path benches/Cargo.toml


wasmi is primarily distributed under the terms of both the MIT license and the APACHE license (Version 2.0), at your choice.



Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in wasmi by you, as defined in the APACHE 2.0 license, shall be dual licensed as above, without any additional terms or conditions.

  • interpreter pauses

    interpreter pauses


    I'm currently developing serverless-wasm and I'm wondering how I could implement two features:

    • putting a hard limit on the run time for a function (real time, or number of opcodes)
    • supporting asynchronous networking in host functions. Something like, WASM side calls tcp_connect, host creates the connection, stops the interpreter right there, and resumes once the connection is established

    From what I understand, I could proceed like this (for the async part):

    • have some host function return a custom trap to say "WouldBlock" and registers that we're waiting for a specific socket
    • write another version of Interpreter::start_execution that would store the function context when receiving that trap from Interpreter::run_interpreter_loop instead of dropping it
    • once the code calling the interpreter knows the connection is established (or we got an error), modify the function stack to push the return value
    • resume executing from there

    It looks like it would be doable, and could be used to implement breakpoints, too.

    The other feature, limiting the run time of a function, would probably be easier to implement, with the loop regularly checking that we do not exceed some limit passed as arguments.

    Do you think those features would be useful in wasmi? The serverless-wasm project is in very early stage, and I admit the readme is not too serious, but I really want to get it to a state where it's nice to use, and I need at least the async networking feature to get it.

    opened by Geal 23
  • Add no_std support

    Add no_std support

    This PR should contain no breaking changes.

    • Add a std feature, enabled by default and sync it with parity-wasm/std
    • Remove uses of std::io
    • Change to a HashMap implementation that works on alloc
    • Disable std::error for no_std
    • The biggest change is using core and alloc everywhere and substituting std if available. This is -- as far as I know -- the accepted way to support no_std (as mentioned in the alloc RFC).

    no_std should probably be added to the Travis configuration. Nom has a working no_std Travis: https://github.com/Geal/nom/blob/master/.travis.yml.

    opened by jrakow 20
  • How to access linear memory from rust code that is compiled to wasm

    How to access linear memory from rust code that is compiled to wasm

    Hi, I'm not sure the best place to ask this type of question, so apologies if this is not it. Just let me know where and I'll ask there. (this relates to a previous question of mine: https://github.com/paritytech/wasmi/issues/166)

    I am writing an app that used a series of "library" functions that are written in rust and compiled to wasm modules (I'll call this the 'rust-wasm' side).

    The app (written in rust and compiled native so I'll call it the 'rust-native' side) loads and executes these modules from files using wasmi. This is working just fine.

    However, I am attempting to pass some complex structs back and fore over the rust-native/rust-wasm boundary:

    • serializing to linear memory in 'rust-native' side and setting linear memory using wasmi function
    • loading the module, executing the exported function using wasmi
    • the function (running as wasm) reads the lineary memory, deserializes the data and use it (on the 'rust-wasm' side)

    does that make sense?

    I would like to know if I can use wasmi library functions to read the linear memory on the "wasm side"?

    The code would be something like this, but instead of allocating the memory, it would just be getting a reference to the linear memory passed to it.

        let linear_memory = MemoryInstance::alloc(Pages(1), None).unwrap();
        let input_data = linear_memory.get(0, input_data_length as usize).unwrap().as_slice();
        // deserialize data into struct
        // run algorithm on struct 

    But remember, this would be compiled to wasm, and be interpreted by wasmi.

    Thanks for any help!

    opened by andrewdavidmackenzie 17
  • CI: Add Wasmtime based Wasm benchmark automation

    CI: Add Wasmtime based Wasm benchmark automation

    Addresses https://github.com/paritytech/wasmi/issues/443

    Pipeline updated and now is divided in two stages, benchmarks (perform benchmarking) and report parses results, generate report and post it into PR.

    opened by sergejparity 15
  • feat(vm): avoid host error subtyping with generics

    feat(vm): avoid host error subtyping with generics

    This PR get rid of the HostError subtyping. We simply introduce a new associated type Error in Externals and build a hierarchy of errors. Instead of trying to embed the host error in the interpreter error, we inverse the dependency. The interpreter will yield a user error that can embed the interpreter error via From.

    The code get simplified and the user is now able to have Copy, Clone, PartialEq, Eq on the error type, hence also simplifying the code calling wasmi (no more ugly Box<&dyn ...). By default, the user is able to use wasmi::Error as it can embed itself. A small drawback is that the NopExternals now require a PhantomData to track the actual error. Free from the perspective of performance though.

    Tests/doctests have been updated accordingly.

    opened by hussein-aitlahcen 15
  • Reconsider the limits

    Reconsider the limits

    We need to reconsider the limits (particularly maximal value and frame stack height). Ideally we should provide a way for a user to change this limits.

    Also, we might want to synchronize with limits.h

    opened by pepyakin 15
  • `wasmi_wasi` cannot be built on Windows on Rust `nightly`

    `wasmi_wasi` cannot be built on Windows on Rust `nightly`

    Thanks for #563 solving the problem, but a degraded wiggle introduces an old cap-primitives, which introduces more problems:

    error[E0277]: the trait bound `file_type::FileType: std::sealed::Sealed` is not satisfied                                                                                                 
       --> C:\Users\Straw\.cargo\registry\src\github.com-1ecc6299db9ec823\cap-primitives-0.25.3\src\fs\file_type.rs:134:6
    134 | impl std::os::windows::fs::FileTypeExt for FileType {
        |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::sealed::Sealed` is not implemented for `file_type::FileType`
        = help: the following other types implement trait `std::sealed::Sealed`:
                and 11 others
    note: required by a bound in `std::os::windows::fs::FileTypeExt`
       --> D:\Straw\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\std\src\os\windows\fs.rs:507:24
    507 | pub trait FileTypeExt: Sealed {
        |                        ^^^^^^ required by this bound in `std::os::windows::fs::FileTypeExt`
    For more information about this error, try `rustc --explain E0277`.
    error: could not compile `cap-primitives` due to previous error
    opened by Berrysoft 13
  • added downcast functionality to Box<dyn HostError>

    added downcast functionality to Box

    @pepyakin Sorry for so many small PRs one after the other, this time I made sure the code does what i need it to, and added a documentation test. The last missing piece was adding by-value downcasting functionality (as opposed to the by-reference downcast). I use the downcast-rs crate here which provides a handy shortcut to implementing this but there's no magic happening there, as you can see in its docs. It also supports no_std as you can see. Now I can write code like this:

    let wasmi_error = /* Something that returns an instance of wasmi::Error */;
    match wasmi_error.try_into_host_error() {
      // host_error: Box<dyn HostError>
      Ok(host_error) => match host_error.downcast::<MyError>() {
        Ok(my_error) => /* my_error is a Box<MyError>. I can get my error object by unboxing it */,
        Err(host_error) => /* I got the host error back */,
      Err(wasmi_error) => /* I got the original error object back */,
    opened by reuvenpo 12
  • feat: make Module::imports be `pub`

    feat: make Module::imports be `pub`

    If we want to create stub function, we must need to know the imports info.

    I think substrate also need this method to do prepare_import like wasmtime.

    opened by yjhmelody 10
  • CNCF SIG-Runtime Discussion/Presentation?

    CNCF SIG-Runtime Discussion/Presentation?

    Hello wasmi team,

    I'm one of the co-chairs of the CNCF SIG-Runtime, I'm reaching out and think it would be great for you to present/discuss the project at one of our meetings. An overview of the project would be great.

    Let me know if this something you'd be interested in doing. If yes, please feel free to add it to our agenda or reach out to me (raravena80 at gmail.com)


    opened by raravena80 10
  • Expose globals to host

    Expose globals to host

    The use case is so that they may be reset to their starting value, to get stateless repeated execution of a module. This is done by making global_by_index pub and adding globals getter. I'm totally open to better ways of doing this.

    opened by leoyvens 10
  • CLI: Add WASI support

    CLI: Add WASI support

    PR adds wasi support to wasmi_cli.

    Notable changes:

    • --dir flag: allows pre-opening of directories with which hosts protect guests from accessing only directories they want. i.e. wasi sandboxing in action.
    • --env flag: allows users to set environment variables
    • --tcplisten flag: pre-open sockets. wasi sandboxing.


    • All three resources (directories, environment vars, sockets) are pre-provided to the guest program through the above flags.
    • All three flags can occur multiple times in any order.
    • wasmi_cli makes WASI available to all programs.
    opened by OLUWAMUYIWA 2
  • Add support for WASI in `wasmi_cli`

    Add support for WASI in `wasmi_cli`

    Currently the CLI tool wasmi_cli does not support the very recent WASI support in the wasmi workspace. (https://github.com/paritytech/wasmi/tree/master/crates/wasi) Before wasmi_cli is actually useful to many users we want it to support WASI as currently supported by wasmi based on Wasmtime's wiggle and wasi-common crates.

    In order to do that wasmi_cli also needs to implement a few additional CLI options:

            --tcplisten <SOCKET ADDRESS>
                Grant access to the given TCP listen socket
            --dir <DIRECTORY>
                Grant access to the given host directory
            --env <KEY>=<VALUE>
                Defines the environment variable for use in the WASI executable

    This issue is following implementation of those options as well as built-in WASI support for wasmi_cli. As a follow-up we can (and will) release wasmi_cli on crates.io.

    As in the Wasmtime CLI application the three flags tcplisten, dir, env can be used multiple times position independent in the argument list of the CLI application, e.g.:

    wasmi_cli --dir foo --env BAR=42 --tcplisten --env BAZ=true --dir bar/baz --env BOOF=BAAF hello.wasm hello_world Barbaz

    Abstract arguments list:

    wasmi_cli <OPTIONS>... <WASM_FILE> <WASM_FUNC> <FUNC_ARGS>...

    Where options are tcplisten, env or dir.

    opened by Robbepop 0
  • Unexpected behavior with load/store alignment

    Unexpected behavior with load/store alignment


    Current State

    Output: 65508521924046110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000


    An exception indicating that "alignment must not be larger than natural"


    • Code Version: git commit id fdc136f57d7cf3a0f184debe00bdf29e373f6326
    • Hardware Architecture: x86_64
    • Operating system: Ubuntu 20.04

    Steps to Reproduce


    1. build the wasmi
    2. run the test case by wasmi <test_case_name> to_test
    opened by erxiaozhou 11
  • Unexpected NaN sign value on the stack

    Unexpected NaN sign value on the stack


    Current State

    0x0 0x0 0x0 0x2f 0x0 0x0 0xf0 0xff


    ........ 0xf8 0xff (The most significant bit of payload is 1)


    • Code Version: git commit id fdc136f57d7cf3a0f184debe00bdf29e373f6326
    • Hardware Architecture: x86_64
    • Operating system: Ubuntu 20.04

    Steps to Reproduce


    1. build the wasmi
    2. run the test case by wasmi <test_case_name> to_test
    opened by erxiaozhou 2
  • Allow for multiple `wasmi::Engine` backends

    Allow for multiple `wasmi::Engine` backends

    Currently wasmi only supports a single Engine to execute Wasm bytecode.

    The engine that is currently in use is a simple stack machine that translates incoming Wasm bytecode into wasmi bytecode that is optimized for efficient execution. But still, the instruction set is modelled after a stack machine just as Wasm bytecode is.

    There is ongoing work to experiment with other models of execution that are based on more efficient machine types such as a register machine. However, experimentation with new engine types and comparison with the existing wasmi engine in use is difficult since the current wasmi architecture does not allow for multiple engine backends. Therefore new engines have to replace the old one.

    However, different engine backends might have different advantages. Therefore having multiple different engines at hand might be very useful to certain users. Besides the classic stack machine based engine backend and the experimental register machine backend there might also be room for an engine backend specialized for debugging that can act as a timetravel debugger as well as even JIT based engine backends.

    For that we need to find proper interfaces for wasmi that allow for this flexibility.

    Workspace Design

    Currently we have wasmi, wasmi_core and wasmi_arena crates in the workspace. For our purposes of allowing different wasmi engine backends we need to split up the big wasmi crate into several chunks and turn it into an umbrella crate finally.

    The crates we are going to need for proper decoupling of concerns are:

    • wasmi_engine
      • Depends on: wasmparser-nostd, wasmi_core, wasmi_arena
      • Depended on by: wasmi_vm, any wasmi backend crate
      • Description: Contains definitions common to all wasmi engine backends and defines engine agnostic interfaces.
      • Exposes: Generic Engine<T> where T is the chosen engine backend implementation as well as EngineBackend trait that T needs to satisfy.
    • wasmi_vm
      • Depends on: wasmi_engine, wasmi_core, wasmi_arena, wasmparser-nostd
      • Depended on by: wasmi, any wasmi backend crate
      • Description: Contains common Wasm definitions such as Store, Memory, Table, Global, Func, Module, Instance etc. Basically this defines most of what today's wasmi crate does.
      • Exposes: An API similar to today's wasmi crate without the UX specific parts.
    • wasmi_stackmachine
      • Depends on: wasmi_engine, wasmi_vm, wasmi_core, wasmi_arena
      • Depended on by: wasmi (for its default engine feature)
      • Description: Contains the definitions specific to the current wasmi engine implementation.
      • Exposes: A single type StackMachine that can be used as parameter for the generic wasmi_engine::Engine<T>.
    • wasmi_regmachine
      • Depends on: wasmi_engine, wasmi_vm, wasmi_core, wasmi_arena
      • Depended on by: Users of wasmi.
      • Description: Contains the definitions specific to the experimental register machine wasmi engine backend.
      • Exposes: A single type RegisterMachine that can be used as parameter for the generic wasmi_engine::Engine<T>.
    • wasmi
      • Depends on: wasmi_vm, wasmi_core, wasmi_stackmachine (optionally)
      • Depended on by: Users of wasmi.
      • Description: Umbrella crate that does not define anything by itself but depends on different wasmi workspace crates to expose a common user friendly API to the outside world. This is the crate which users of wasmi will depend on.
      • Exposes: An API similar to today's wasmi crate with additional default engine crate feature.

    ToDo List (in order)

    • [ ] Create the wasmi_engine crate. Make wasmi crate depend on it.
      • At this point the wasmi stack machine engine backend still resides within the wasmi crate itself.
      • Engine agnostic and common engine definitions no longer are defined within the wasmi after after this point.
    • [ ] Rename the wasmi crate to wasmi_vm and create the new wasmi umbrella crate that simply reexports wasmi_vm mostly.
    • [ ] Create the wasmi_stackmachine crate. Introduce default-engine default crate feature to wasmi umbrella crate.
      • After this task the wasmi_vm crate no longer contains any engine backend implementation.
    • [ ] Create the wasmi_regmachine crate based on https://github.com/paritytech/wasmi/pull/367.
      • After this task we can finally merge the register machine implementation PR for experimentation purposes.


    opened by Robbepop 0
  • v0.21.0(Jan 4, 2023)


    • Add support for resumable function calls. (https://github.com/paritytech/wasmi/pull/598)
      • This feature allows to resume a function call upon encountering a host trap.
    • Add support for concurrently running function executions using a single wasmi engine.
      • This feature also allows to call Wasm functions from host functions. (https://github.com/paritytech/wasmi/pull/590)
    • Add initial naive WASI support for wasmi using the new wasmi_wasi crate. (https://github.com/paritytech/wasmi/pull/557)
      • Special thanks to Onigbinde Oluwamuyiwa Elijah for carrying the WASI support efforts!
      • Also thanks to Yuyi Wang for testing and improving initial WASI support. (https://github.com/paritytech/wasmi/pull/592, https://github.com/paritytech/wasmi/pull/571, https://github.com/paritytech/wasmi/pull/568)
      • Note: There is ongoing work to integrate WASI support in wasmi_cli so that the wasmi CLI will then be able to execute arbitrary wasm-wasi files out of the box in the future.
    • Add Module::imports that allows to query Wasm module imports. (https://github.com/paritytech/wasmi/pull/573, https://github.com/paritytech/wasmi/pull/583)


    • Fix a bug that imported linear memories and tables were initialized twice upon instantiation. (https://github.com/paritytech/wasmi/pull/593)
    • The wasmi CLI now properly hints for file path arguments. (https://github.com/paritytech/wasmi/pull/596)


    • The wasmi::Trap type is now more similar to Wasmtime's Trap type. (https://github.com/paritytech/wasmi/pull/559)
    • The wasmi::Store type is now Send and Sync as intended. (https://github.com/paritytech/wasmi/pull/566)
    • The wasmi CLI now prints exported functions names if the function name CLI argument is missing. (https://github.com/paritytech/wasmi/pull/579)
    • Improve feedback when running a Wasm module without exported function using wasmi CLI. (https://github.com/paritytech/wasmi/pull/584)
    Source code(tar.gz)
    Source code(zip)
  • v0.20.0(Nov 4, 2022)


    • Added contribution documentation about fuzz testing. (https://github.com/paritytech/wasmi/pull/529)


    • Removed some deprecated functions in the wasmi_core crate. (https://github.com/paritytech/wasmi/pull/545)


    • Fixed a critical performance regression introduced in Rust 1.65. (https://github.com/paritytech/wasmi/pull/518)
      • While the PR's main job was to clean up some code it was found out that it also fixes a critical performance regression introduced in Rust 1.65.
      • You can read more about this performance regression in this thread.


    • Fixed handling of edge cases with respect to Wasm linear memory. (https://github.com/paritytech/wasmi/pull/449)
      • This allows for wasmi to properly setup and use linear memory instances of up to 4GB.
    • Optimize and improve Wasm instantiation. (https://github.com/paritytech/wasmi/pull/531)
    • Optimize global.get of immutable non-imported globals. (https://github.com/paritytech/wasmi/pull/533)
      • Also added a benchmark test for this. (https://github.com/paritytech/wasmi/pull/532)


    • Implemented miscellaneous improvements to our CI system.
      • https://github.com/paritytech/wasmi/pull/539 (and more)
    • Miscellaneous clean ups in wasmi_core and wasmi's executor.
      • https://github.com/paritytech/wasmi/pull/542 https://github.com/paritytech/wasmi/pull/541 https://github.com/paritytech/wasmi/pull/508 https://github.com/paritytech/wasmi/pull/543
    Source code(tar.gz)
    Source code(zip)
  • v0.19.0(Oct 20, 2022)


    • Fixed a potential undefined behavior as reported by the miri tool with respect to its experimental stacked borrows. (https://github.com/paritytech/wasmi/pull/524)


    • Optimized Wasm to wasmi translation phase by removing unnecessary Wasm validation type checks. (https://github.com/paritytech/wasmi/pull/527)
      • Speedups were in the range of 15%.
    • Linker::instantiate now takes &self instead of &mut self. (https://github.com/paritytech/wasmi/pull/512)
      • This allows users to easily predefine a linker and reused its definitions as shared resource.
    • Fixed a bug were Caller::new was public. (https://github.com/paritytech/wasmi/pull/514)
      • It is now a private method as it was meant to be.
    • Optimized TypedFunc::call at slight cost of Func::call. (https://github.com/paritytech/wasmi/pull/522)
      • For many parameters and return values the measured improvements are in the range of 25%. Note that this is only significant for a large amount of host to Wasm calls of small functions.


    • Added new benchmarks and cleaned up benchmarking code in general.
      • https://github.com/paritytech/wasmi/pull/525 https://github.com/paritytech/wasmi/pull/526 https://github.com/paritytech/wasmi/pull/521
    • Add miri testing to wasmi CI (https://github.com/paritytech/wasmi/pull/523)
    Source code(tar.gz)
    Source code(zip)
  • v0.18.1(Oct 13, 2022)


    • Optimize for common cases for branch and return instructions. (https://github.com/paritytech/wasmi/pull/493)
      • This led to up to 10% performance improvement according to our benchmarks in some cases.
    • Removed extraneous S: impl AsContext generic parameter from Func::typed method.
    • Make IntoFunc, WasmType and WasmRet traits publicly available.
    • Add missing impl for WasmRet for Result<T, Trap> where T: WasmType.
      • Without this impl it was impossible to provide closures to Func::wrap that returned Result<T, Trap> where T: WasmType, only Result<(), Trap> or Result<(T,), Trap> was possible before.


    • Added wasmi_arena crate which defines all internally used arena data structures. (https://github.com/paritytech/wasmi/pull/502)
    • Update to clap 4.0 in wasmi_cli. (https://github.com/paritytech/wasmi/pull/498)
    • Many more improvements to our internal benchmarking CI. (https://github.com/paritytech/wasmi/pull/494, https://github.com/paritytech/wasmi/pull/501, https://github.com/paritytech/wasmi/pull/506, https://github.com/paritytech/wasmi/pull/509)
    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(Oct 2, 2022)


    • Added Contibution Guidelines and Code of Conduct to the repository. (https://github.com/paritytech/wasmi/pull/485)


    • Optimized instruction dispatch in the wasmi interpreter. (https://github.com/paritytech/wasmi/pull/478, https://github.com/paritytech/wasmi/pull/482)
      • This yielded combined speed-ups of ~20% across the board.
      • As a side effect we also refactored the way we compute branching offsets at Wasm module compilation time which improved performance of Wasm module compilation by roughly 5%.


    • Our CI now also benchmarks wasmi when ran inside Wasmtime as Wasm. (https://github.com/paritytech/wasmi/pull/483, https://github.com/paritytech/wasmi/pull/487)
      • This allows us to optimize wasmi towards Wasm performance more easily in the future.
    Source code(tar.gz)
    Source code(zip)
  • v0.17.0(Sep 23, 2022)


    • Added Memory::data_and_store_mut API inspired by Wasmtime's API. (https://github.com/paritytech/wasmi/pull/462)


    • Updated wasmparser-nostd dependency from 0.90.0 to 0.91.0.
      • This improved performance of Wasm module compilation by ~10%.
    • Updated wasmi_core from 0.3.0 to 0.4.0.
    • Optimized execution of several Wasm float to int conversion instructions. (https://github.com/paritytech/wasmi/pull/439)
      • We measured a performance improvement of 6000% or in other words those instructions are now 60 times faster than before.
      • This allowed us to remove the big num-rational dependency from wasmi_core for some nice speed-ups in compilation time of wasmi itself.
    • Optimized global.get and global.set Wasm instruction execution. (https://github.com/paritytech/wasmi/pull/427)
      • This improved performance of those instructions by up to 17%.
    • Optimized Wasm value stack emulation. (https://github.com/paritytech/wasmi/pull/459)
      • This improved performance of compute intense workloads by up to 23%.


    • Added automated continuous benchmarking to wasmi. (https://github.com/paritytech/wasmi/pull/422)
      • This allows us to have a more consistent overview over the performance of wasmi.
    • Updated criterion benchmarking framework to version 0.4.0.
    • Reuse allocations during Wasm validation and translation:
      • Wasm validation and translation combined. (https://github.com/paritytech/wasmi/pull/462)
      • Wasm br_table translations. (https://github.com/paritytech/wasmi/pull/440)
    • Enabled more useful clippy lints for wasmi and wasmi_core. (https://github.com/paritytech/wasmi/pull/438)
    • Reorganized the wasmi workspace. (https://github.com/paritytech/wasmi/pull/466)
    Source code(tar.gz)
    Source code(zip)
  • v0.13.2(Sep 20, 2022)

    Note: This is going to be the last release with the legacy wasmi engine. Future releases are going to use the new Wasm execution engines that are currently in development. We may consider to publish the legacy wasmi engine as wasmi-legacy crate.


    • Support allocating 4GB of memory (https://github.com/paritytech/wasmi/pull/452)
    Source code(tar.gz)
    Source code(zip)
  • v0.16.0(Aug 30, 2022)


    • Update wasmparser-nostd dependency from version 0.83.0 -> 0.90.0. Link:
      • This significantly improved wasmi's Wasm parsing, validation and Wasm to wasmi bytecode translation performance.


    • Transition to the new wasmparser::VisitOperator API. Link
      • This again significantly improved wasmi's Wasm parsing, validation and Wasm to wasmi bytecode translation performance by avoiding many unnecessary unpredictable branches in the process.
    Source code(tar.gz)
    Source code(zip)
  • v0.15.0(Aug 22, 2022)


    • Fixed bugs found during fuzzing the translation phase of wasmi. Link
    • Fix Read trait implementation for no_std compilations. Link


    • Update to wasmi_core version 0.3.0.
    • Changed API of wasmi::Config in order to better reflect the API of wasmtime::Config.
    • Refactor Trap type to be of pointer size which resulted in significant performance wins across the board especially for call intense work loads. Link


    • Removed support for virtual memory based Wasm linear memory. We decided to remove support since benchmarks showed that our current implementation actually regresses performance compared to our naive Vec based implementation. Link


    • The wasmi::Engine now caches the bytes of the default linear memory for performance wins in memory.store and memory.load intense work loads. Link
    • The wasmi engine internals have been reorganized and modernised to improve performance on function call intense work loads. This resulted in performance improvements across the board. Link
    • The Wasm to wasmi bytecode translation now properly reuses heap allocations across function translation units which improved translation performance by roughly 10%. Link
    • Optimized the wasmi engine Wasm value stack implementation for significant performance wins across the board. Link
    • Shrunk size of some internal identifier types for minor performance wins. Link
    • Added initial naive fuzz testing for Wasm parsing, validation and Wasm to wasmi bytecode translation. Link
    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(Jul 26, 2022)



    • Wasmi has been entirely redesigned and reimplemented. This work resulted in an entirely new API that is heavily inspired by the Wasmtime API, a brand new Wasm execution engine that performs roughly 30-40% better than the previous engine according to our benchmarks, the support of many Wasm proposals and Wasm parsing and validation using the battle tested wasmparser crate by the BytecodeAlliance.

      The new wasmi design allows to reuse the Wasm execution engine resources instead of spinning up a new Wasm execution engine for every function call.

      Note: If you plan to use wasmi it is of critical importance to compile wasmi using the following Cargo profile settings:

      lto = "fat"
      codegen-units = 1

      If you do not use these profile settings you might risk regressing performance of wasmi by up to 400%. You can read more about this issue here.


    • Removed support for resuming function execution. We may consider to add this feature back into the new engine. If you are a user of wasmi and want this feature please feel free to open an issue and provide us with your use case.
    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(Jul 25, 2022)

    Note: This is going to be the last release with the legacy wasmi engine. Future releases are going to use the new Wasm execution engines that are currently in development. We may consider to publish the legacy wasmi engine as wasmi-legacy crate.


    • Update dependency: wasmi-validation v0.4.2 -> v0.5.0
    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(Jul 24, 2022)

    Note: This is going to be the last release with the legacy wasmi engine. Future releases are going to use the new Wasm execution engines that are currently in development. We may consider to publish the legacy wasmi engine as wasmi-legacy crate.


    • wasmi now depends on the wasmi_core crate.
    • Deprecated RuntimeValue::decode_{f32,f64} methods.
      • Reason: These methods expose details about the F32 and F64 types. The RuntimeValue type provides from_bits methods for similar purposes.
      • Replacement: Replace those deprecated methods with F{32,64}::from_bits().into() respectively.
    • Refactor traps in wasmi: PR
      • This change also renames TrapKind to TrapCode.
      • The wasmi crate now properly reuses the TrapCode definitions from the wasmi_core crate.
    • Updated dependency:
      • parity-wasm v0.42 -> v0.45
      • memory_units v0.3.0 -> v0.4.0


    • Rename RuntimeValue to Value internally.
    • Now uses wat crate dependency instead of wabt for reading .wat files in tests.
    • Updated dev-dependencies:
      • assert_matches: v1.1 -> v1.5
      • rand 0.4.2 -> 0.8.2
    • Fix some clippy warnings.
    Source code(tar.gz)
    Source code(zip)
  • v0.11.0(Jan 6, 2022)


    • Make wasmi traps more conformant with the Wasm specification. (https://github.com/paritytech/wasmi/pull/300)
    • Fixed a bug in {f32, f64}_copysign implementations. (https://github.com/paritytech/wasmi/pull/293)
    • Fixed a bug in {f32, f64}_{min, max} implementations. (https://github.com/paritytech/wasmi/pull/295)


    • Optimized Wasm to host calls. (https://github.com/paritytech/wasmi/pull/291)
      • In some artificial benchmarks we saw improvements of up to 42%!
    • Introduce a more efficient LittleEndianConvert trait. (https://github.com/paritytech/wasmi/pull/290)


    • Refactor and clean up benchmarking code and added more benchmarks.
      • https://github.com/paritytech/wasmi/pull/299
      • https://github.com/paritytech/wasmi/pull/298
    • Apply some clippy suggestions with respect ot #[must_use]. (https://github.com/paritytech/wasmi/pull/288)
    • Improve Rust code formatting of imports.
    • Improve debug impl of ValueStack so that only the live parts are printed.
    Source code(tar.gz)
    Source code(zip)
  • v0.10.0(Jan 6, 2022)


    • Support for virtual memory usage on Windows 64-bit platforms.
      • Technically we now support the same set of platforms as the region crate does: https://github.com/darfink/region-rs#platforms


    • The wasmi and wasmi-validation crates now both use Rust edition 2021.
    • The README now better teaches how to test and benchmark the crate.
    • Updated num-rational from version 0.2.2 -> 0.4.0.


    • Deprecated MemoryInstance::get method.
      • Users are recommended to use MemoryInstance::get_value or MemoryInstance::get_into methods instead.


    • Removed support for virtual memory on 32-bit platforms.
      • Note that the existing support was supposedly not more efficient than the Vec based fallback implementation anyways due to technical design.
    • Removed the core crate feature that previously has been required for no_std builds.
      • Now users only have to specify --no-default-features for a no_std build.


    • Fully deploy GitHub Actions CI and remove deprecated Travis based CI. Added CI jobs for:
      • Testing on Linux, MacOS and Windows
      • Checking docs and dead links in docs.
      • Audit crate dependencies for vulnerabilities.
      • Check Wasm builds.
      • File test coverage reports to codecov.io.
    Source code(tar.gz)
    Source code(zip)
Parity Technologies
Solutions for a trust-free world
Parity Technologies
`wasm-snip` replaces a WebAssembly function's body with an `unreachable`

wasm-snip wasm-snip replaces a Wasm function's body with an unreachable instruction. API Docs | Contributing | Chat Built with ?? ?? by The Rust and W

Rust and WebAssembly 177 Dec 28, 2022
Mod_wasm - an extension module for the Apache HTTP Server (httpd) that enables the usage of WebAssembly (Wasm).

mod_wasm is an extension module for the Apache HTTP Server (httpd) that enables the usage of WebAssembly (Wasm). This module will allow to execute certain tasks in the backend in a very efficient and secure way.

VMware  Labs 67 Dec 21, 2022
Low level tooling for WebAssembly in JavaScript using wasm-tools

js-wasm-tools js-wasm-tools compiles some of the API of wasm-tools to JavaScript and WebAssembly via wasm-bindgen. This offers low level tooling for W

Dominic Elm 59 Dec 19, 2022
Distribute a wasm SPA as HTML by wrapping it as a polyglot "html+wasm+zip"

A packer that adds a webpage to WASM module, making it self-hosted! Motivation At the moment, Browsers can not execute WebAssembly as a native single

Andreas Molzer 3 Jan 2, 2023
👾 Run WebAssembly (WASM-4) games on small devices (like PyBadge)

?? gamgee Run WebAssembly (WASM-4) games on small devices. Gamgee is a WASM-4 games emulator written in Rust and designed to be executed on devices wi

Orsinium Labs 5 Feb 27, 2024
Rust bindings for the Python interpreter

PyO3 Rust bindings for Python. This includes running and interacting with Python code from a Rust binary, as well as writing native Python modules. Us

PyO3 7.2k Jan 4, 2023
A memory safe Lua interpreter

Hematita Da Lua Hematita Da Lua is an interpreter for the scripting language Lua, written entirely in 100% safe Rust. Hematita is the portugese word f

Daniel 149 Dec 29, 2022
A simple Pascal interpreter written in rust.

rascal A simple Pascal interpreter written in rust. Usage Download the latest rascal executable from the release page. Run the executable. rascal.exe

null 47 Dec 7, 2022
An interpreter for the esoteric programming language, Brainf*ck.

Brainf*ck Interpreter This is just a normal Brainf*ck interpreter written in Rust. If you don't know what Brainf*ck is, you can check out the wikipedi

Callum Irving 0 Dec 23, 2021
Pyo3 - Rust bindings for the Python interpreter

PyO3 Rust bindings for Python, including tools for creating native Python extension modules. Running and interacting with Python code from a Rust bina

PyO3 7.2k Jan 2, 2023
RustPython - A Python Interpreter written in Rust

RustPython A Python-3 (CPython >= 3.9.0) Interpreter written in Rust ?? ?? ?? . Usage Check out our online demo running on WebAssembly. RustPython req

null 13.3k Jan 2, 2023
Lisp interpreter that might be fast someday maybe?

ehlisp Pronunciation I'm not really sure. Maybe like an incorrect pronunciation of "ellipse", like "ellisp"? Also maybe like "a lisp". I named it this

Eddie Hatfield 3 Oct 6, 2022
A simple interpreter language written in Rust.

Glang Backstory Hello and welcome to the Glang git repository. Game Slang or in short Glang is a super simple interpreted language written in Rust wit

null 6 Nov 12, 2022
📦✨ your favorite rust -> wasm workflow tool!

?? ✨ wasm-pack Your favorite Rust → Wasm workflow tool! Docs | Contributing | Chat Built with ?? ?? by The Rust and WebAssembly Working Group About Th

Rust and WebAssembly 4.8k Jan 5, 2023
Facilitating high-level interactions between Wasm modules and JavaScript

wasm-bindgen Facilitating high-level interactions between Wasm modules and JavaScript. Guide | API Docs | Contributing | Chat Built with ?? ?? by The

Rust and WebAssembly 5.9k Jan 8, 2023
WebAssembly implementation from scratch in Safe Rust with zero dependencies

wain wain is a WebAssembly INterpreter written in Rust from scratch with zero dependencies. An implementation of WebAssembly. Features: No unsafe code

Linda_pp 328 Jan 2, 2023
A notebook app integrated with todo lists utility. Developed with Rust, WebAssembly, Yew and Trunk.

Flow.er A notebook app integrated with todo-list utility. Project flow.er is a Rust WASM app running in browser. Taking advantage of Yew and Trunk, it

null 45 Dec 31, 2022
NPM package distributing biscuit in WebAssembly for web components

Biscuit playground This is an example application for Biscuit tokens, where you can manipulate tokens and their verification in your browser. build wi

null 0 Dec 30, 2021
Gun port in rust & wasm

gun-rs-wasm Rust & WASM port of Gun. For a non-wasm version, check out gun-rs Example (source) Use npm install rusty-gun import { Node as Gun } from "

Martti Malmi 39 Dec 19, 2022