WebAssembly (Wasm) interpreter.

Parity Technologies

Last update: Jan 4, 2023

Related tags

Overview

Continuous Integration	Test Coverage	Documentation	Crates.io

`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

Building

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

Testing

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.

Platforms

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

Features

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

cargo build --features virtual_memory

Benchmarks

In order to benchmark wasmi use the following command:

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

License

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

See LICENSE-APACHE and LICENSE-MIT for details.

Contribution

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.

Comments

interpreter pauses
hello,

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
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
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

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

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

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
legavy-wasmi

opened by pepyakin 15

`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`:
              Child
              Command
              ExitCode
              ExitStatus
              ExitStatusError
              File
              OsStr
              OsString
            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
@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`

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?

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)

Thanks!

opened by raravena80 10
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
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.

Note

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`
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 123.0.0.1:8080 --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
Description

Current State

Output: 65508521924046110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Expected

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

Environment

Code Version: git commit id fdc136f57d7cf3a0f184debe00bdf29e373f6326

Hardware Architecture: x86_64

Operating system: Ubuntu 20.04

Steps to Reproduce

wasmi.zip

build the wasmi

run the test case by wasmi <test_case_name> to_test
opened by erxiaozhou 11
Unexpected NaN sign value on the stack
Description

Current State

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

Expected

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

Environment

Code Version: git commit id fdc136f57d7cf3a0f184debe00bdf29e373f6326

Hardware Architecture: x86_64

Operating system: Ubuntu 20.04

Steps to Reproduce

wasmi.zip

build the wasmi

run the test case by wasmi <test_case_name> to_test
opened by erxiaozhou 2
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.

enhancement
opened by Robbepop 0

Releases(v0.21.0)

v0.21.0(Jan 4, 2023)
Added

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)

Fixed

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)

Changed

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

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

Removed

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

Fixed

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.

Changed

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)

Internal

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

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)

Changed

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.

Internal

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)
Changed

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.

Internal

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

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

Changed

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%.

Internal

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

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

Changed

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%.

Internal

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.

Fixed

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)
Changed

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.

Internal

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

Fixed bugs found during fuzzing the translation phase of wasmi. Link

Fix Read trait implementation for no_std compilations. Link

Changed

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

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

Internal

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)
Added

Added support for the following Wasm proposals:

Import and export of mutable globals

Non-trapping float-to-int conversions

Sign-extension operators

Multi-value

We plan to support more Wasm proposals in the future.

Changed

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:

[profile.release] 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

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.

Changed

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.

Changed

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

Internal

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)
Fixed

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)

Changed

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)

Internal

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)
Added

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

Changed

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

Deprecated MemoryInstance::get method.

Users are recommended to use MemoryInstance::get_value or MemoryInstance::get_into methods instead.

Removed

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.

Internal

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)