JSPM

  • ESM via JSPM
  • ES Module Entrypoint
  • Export Map
  • Keywords
  • License
  • Repository URL
  • TypeScript Types
  • README
  • Created
  • Published
  • Downloads 8573
  • Score
    100M100P100Q180768F
  • License GPL-2.0

WebAssembly interpreter

Package Exports

  • webassembly-interpreter

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (webassembly-interpreter) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

js-webassembly-interpreter

WebAssembly interpreter

This is meant to be a polyfill entirely written in JavaScript.

Examples

Usage

CDN

You can import https://bundle.run/webassembly-interpreter and the webassemblyInterpreter object will be accessible.

npm

npm install webassembly-interpreter

Commands

  • wasmdump FILENAME: decodes a WASM binary and dumps its content
  • wasmast FILENAME: prints the AST of the WASM binary.
  • wasmrun FILENAME [ENTRYPOINT]: runs the WASM binary (uses the start section by default as entrypoint).

Components

Compiler

Code parsing and manipulations.

AST

Tools to manipulate and use our internal AST. You can see its definitions here.

Parsing

The parsing is available for the following formats:

Interpreter

Kernel

Provides core features (memory management, execution, ...).

Memory management

The WebAssembly specification uses a pointer/Addr structure, where some runtime values are stored (like functions). Unfortunately (for me) JavaScript doesn't expose pointers to the user-land.

For now the memory management is backend by an Array, where the Addr is the index. This is subject to change because is doesn't provides the same semantics than manual memory management would.

Note that garbage collection is done by the host (the JavaScript engine), there is probably no need to re-implement. On the other hand we need to unsure that we don't retain unused object.

The call stack

To be as close as possible to a native environement the execution relies on StackFrames (its structure is defined here).

The context in which StackFrames are executed is the call stack.

The stack call depth is unspecified currently by WebAssembly and is controlled by the host environement, its limit might vary.

Runtime

Our runtime instance values.

Signals

  • trap signal which aborts the execution

Notes

Source

The sources are available on GitHub: xtuc/js-webassembly-interpreter.

Licence

GNU General Public License, version 2.