4 ms·

Is there any sort of open source non-browser interpreter for Webassembly?

dubcanada 10y ago
I don't know how useful that would be, it's still javascript (just a lower level version of it) after all. It's coupled pretty tightly with the browser.
- Touche 10y ago
  I think you're confusing asm.js with wasm. wasm is not JavaScript.
- aspirin 10y ago
  WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
  - 0xdeadbeefbabe 10y ago
    > You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
    - smitherfield 10y ago
      Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
      - TazeTSchnitzel 10y ago
        Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).
        hackcasual 10y ago
        Not exactly. You have to export those APIs into the WebAssembly module. It's certainly possible to have a WASM implementation that doesn't provide web APIs, but is still WASM.
    - aspirin 10y ago
      The high level goals of WASM do include access to browser APIs, but the MVP version that is being implemented now, does not yet allow it: https://github.com/WebAssembly/design/blob/master/JS.md https://github.com/WebAssembly/design/blob/master/JS.md WASM code can call external functions defined per module, and the external code can be JS code that interacts with browser APIs. So indirect use of browser APIs is possible.
  - detaro 10y ago
    According to the docs, high-level goals of WASM are to allow synchronous calls to and from JavaScript; enforce the same-origin and permissions security policies; access browser functionality through the same Web APIs that are accessible to JavaScript; ? https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
  - s3th 10y ago
    Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/ http://webassembly.org/getting-started/js-api/
- kibwen 10y ago
  I've also linked this in a sibling comment to yours, but this post from the Rust project developers talks about a few of the potential upsides to a general-purpose compiler backend derived from the WASM initiative: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi... TL;DR: compilers written for the JIT use case are designed to minimize latency (compilation times) while still producing above-average code, so having such an alternative backend would be a boon for regular users of compilers with heavyweight backends (e.g. LLVM, which produces excellent code but at the cost of very large compilation times, even in unoptimized builds). Additionally, a compiler built to process WASM is more security-aware than your typical compiler, and thus won't include optimizations that attempt to exploit undefined behavior (thus losing out on potential optimizing opportunities, but hopefully producing code that's a bit more bulletproof).
- rubber_duck 10y ago
  As others said it has nothing to do with JS, i'd like to add how it's usefull - it's a low level VM spec (lower than say JVM or CLR) so it will hopefully be easy to compile various languages to it (hopefully because they need to fit a GC mechanism in to it yet to support higher level languages) but it's still safe/sandboxed and portable.
kibwen 10y ago
There are nascent plans from the Rust project to retrofit Spidermonkey's WASM compiler (called Cretonne, and which is apparently already written in Rust) to serve as a general-purpose compiler backend: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi...
- AgentME 10y ago
  What does that have to do with a non-browser interpreter? I think you might've responded to the wrong post.
  - kibwen 10y ago
    I believe I've responded to the right post. :) Currently, WASM (and Javascript, when JIT'ed) are lowered to Cretonne IR, which is then optimized and translated to native code by the Cretonne engine, which is then executed by Spidermonkey. What the link above is proposing is to extract Cretonne into a standalone component capable of producing object files which can be linked into other programs as expected. The Rust project would intend to use such a backend by writing a pass to translate Rust to Cretonne IR. However, the important observation is that WASM and Javascript are already being translated to Cretonne IR, which means that if the Rust developers do the work of creating a standalone backend out of Cretonne, then WASM and Javascript should be able to leverage it to produce code that's independent of the browser (though for JS you'd probably need to implement some additional external runtime support).
    - AgentME 10y ago
      So Rust is considering making a general backend which compiles to WASM first and then compiling that to native code, which could be faster and means that they would be creating a general WASM->native compiler in the process? That sounds pretty useful and clever if I'm getting it right.
      - kibwen 10y ago
m12k 10y ago
Here's a Node package: https://www.npmjs.com/package/wasm https://www.npmjs.com/package/wasm
- binji 10y ago
  That appears to use https://github.com/WebAssembly/polyfill-prototype-1 https://github.com/WebAssembly/polyfill-prototype-1, which does not match the current binary format at all. The current way to do the equivalent would be to use Binaryen's asm2wasm tool. https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
- singularity2001 10y ago
  That package is highly deprecated and unnecessary: You can now simply do node --expose-wasm > buffer=fs.readFileSync('test.wasm') > WebAssembly.compile(buffer)
dschuff 10y ago
WABT (https://github.com/WebAssembly/wabt/ https://github.com/WebAssembly/wabt/) and Binaryen (https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen) as well as the spec itself (https://github.com/WebAssembly/spec/tree/master/interpreter https://github.com/WebAssembly/spec/tree/master/interpreter) all have interpreters for the WebAssembly language. What they don't have is the same import and export binding mechanisms that the JavaScript engines have. JS engines can bind wasm imports and exports with JS functions. The interpreters that exist today are great for testing implementations or compilers but don't have interesting capabilities to interact with an embedding environment. There have been a few experiments with non-JS embeddings (for example, implementations build on LLVM which could easily define bindings to native functions) but nothing really usable or productized yet.
pizlonator 10y ago
Part of the spec is a reference interpreter written in OCaml. Edit: link: https://github.com/WebAssembly/spec/tree/master/interpreter https://github.com/WebAssembly/spec/tree/master/interpreter
- nickpsecurity 10y ago
  A semi-formal, reference spec done declaratively in Ocaml using s-expressions for the AST? When did The Right Thing become popular in browser developments!? I'm impressed. Way better than trying to get compatible, correct implementations out of a pile of English and text art as done by some other groups.
  - pizlonator 10y ago
    The jury is still out on whether this interpreter gets to be called a reference spec, or even a spec. It may be a reference interpreter that is offered as a companion to the official English text. It all depends on what others feel comfortable with. But I'd rather that this OCaml program was _the_ spec. I found it enjoyable to read the other day when I was trying to figure out WebAssembly verification semantics. Much better than reading an English description of a verification algorithm.
icefox 10y ago
WAVM https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM Which has some nice capabilities such as the ability to call functions with arguments from the command line wavm ../Test/spec/fac.wast --function fac-iter 5 stdin/stderr/stdout is also supported for pure command line applications all while being sandboxed.
tsavola 10y ago
Here's mine (although it's not an interpreter): https://github.com/tsavola/wag https://github.com/tsavola/wag

I don't know how useful that would be, it's still javascript (just a lower level version of it) after all. It's coupled pretty tightly with the browser.

Touche 10y ago
I think you're confusing asm.js with wasm. wasm is not JavaScript.
aspirin 10y ago
WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
- 0xdeadbeefbabe 10y ago
  > You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
  - smitherfield 10y ago
    Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
    - TazeTSchnitzel 10y ago
      Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).
      - hackcasual 10y ago
        Not exactly. You have to export those APIs into the WebAssembly module. It's certainly possible to have a WASM implementation that doesn't provide web APIs, but is still WASM.
  - aspirin 10y ago
    The high level goals of WASM do include access to browser APIs, but the MVP version that is being implemented now, does not yet allow it: https://github.com/WebAssembly/design/blob/master/JS.md https://github.com/WebAssembly/design/blob/master/JS.md WASM code can call external functions defined per module, and the external code can be JS code that interacts with browser APIs. So indirect use of browser APIs is possible.
- detaro 10y ago
  According to the docs, high-level goals of WASM are to allow synchronous calls to and from JavaScript; enforce the same-origin and permissions security policies; access browser functionality through the same Web APIs that are accessible to JavaScript; ? https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/HighLevelG...
- s3th 10y ago
  Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/ http://webassembly.org/getting-started/js-api/
kibwen 10y ago
I've also linked this in a sibling comment to yours, but this post from the Rust project developers talks about a few of the potential upsides to a general-purpose compiler backend derived from the WASM initiative: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi... TL;DR: compilers written for the JIT use case are designed to minimize latency (compilation times) while still producing above-average code, so having such an alternative backend would be a boon for regular users of compilers with heavyweight backends (e.g. LLVM, which produces excellent code but at the cost of very large compilation times, even in unoptimized builds). Additionally, a compiler built to process WASM is more security-aware than your typical compiler, and thus won't include optimizations that attempt to exploit undefined behavior (thus losing out on potential optimizing opportunities, but hopefully producing code that's a bit more bulletproof).
rubber_duck 10y ago
As others said it has nothing to do with JS, i'd like to add how it's usefull - it's a low level VM spec (lower than say JVM or CLR) so it will hopefully be easy to compile various languages to it (hopefully because they need to fit a GC mechanism in to it yet to support higher level languages) but it's still safe/sandboxed and portable.

kibwen 10y ago

There are nascent plans from the Rust project to retrofit Spidermonkey's WASM compiler (called Cretonne, and which is apparently already written in Rust) to serve as a general-purpose compiler backend: https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275 https://internals.rust-lang.org/t/possible-alternative-compi...

AgentME 10y ago
What does that have to do with a non-browser interpreter? I think you might've responded to the wrong post.
- kibwen 10y ago
  I believe I've responded to the right post. :) Currently, WASM (and Javascript, when JIT'ed) are lowered to Cretonne IR, which is then optimized and translated to native code by the Cretonne engine, which is then executed by Spidermonkey. What the link above is proposing is to extract Cretonne into a standalone component capable of producing object files which can be linked into other programs as expected. The Rust project would intend to use such a backend by writing a pass to translate Rust to Cretonne IR. However, the important observation is that WASM and Javascript are already being translated to Cretonne IR, which means that if the Rust developers do the work of creating a standalone backend out of Cretonne, then WASM and Javascript should be able to leverage it to produce code that's independent of the browser (though for JS you'd probably need to implement some additional external runtime support).
  - AgentME 10y ago
    So Rust is considering making a general backend which compiles to WASM first and then compiling that to native code, which could be faster and means that they would be creating a general WASM->native compiler in the process? That sounds pretty useful and clever if I'm getting it right.
    - kibwen 10y ago

m12k 10y ago

Here's a Node package: https://www.npmjs.com/package/wasm https://www.npmjs.com/package/wasm

binji 10y ago
That appears to use https://github.com/WebAssembly/polyfill-prototype-1 https://github.com/WebAssembly/polyfill-prototype-1, which does not match the current binary format at all. The current way to do the equivalent would be to use Binaryen's asm2wasm tool. https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
singularity2001 10y ago
That package is highly deprecated and unnecessary: You can now simply do node --expose-wasm > buffer=fs.readFileSync('test.wasm') > WebAssembly.compile(buffer)

dschuff 10y ago

WABT (https://github.com/WebAssembly/wabt/ https://github.com/WebAssembly/wabt/) and Binaryen (https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen) as well as the spec itself (https://github.com/WebAssembly/spec/tree/master/interpreter https://github.com/WebAssembly/spec/tree/master/interpreter) all have interpreters for the WebAssembly language. What they don't have is the same import and export binding mechanisms that the JavaScript engines have. JS engines can bind wasm imports and exports with JS functions. The interpreters that exist today are great for testing implementations or compilers but don't have interesting capabilities to interact with an embedding environment. There have been a few experiments with non-JS embeddings (for example, implementations build on LLVM which could easily define bindings to native functions) but nothing really usable or productized yet.

pizlonator 10y ago

Part of the spec is a reference interpreter written in OCaml. Edit: link: https://github.com/WebAssembly/spec/tree/master/interpreter https://github.com/WebAssembly/spec/tree/master/interpreter

nickpsecurity 10y ago
A semi-formal, reference spec done declaratively in Ocaml using s-expressions for the AST? When did The Right Thing become popular in browser developments!? I'm impressed. Way better than trying to get compatible, correct implementations out of a pile of English and text art as done by some other groups.
- pizlonator 10y ago
  The jury is still out on whether this interpreter gets to be called a reference spec, or even a spec. It may be a reference interpreter that is offered as a companion to the official English text. It all depends on what others feel comfortable with. But I'd rather that this OCaml program was _the_ spec. I found it enjoyable to read the other day when I was trying to figure out WebAssembly verification semantics. Much better than reading an English description of a verification algorithm.

icefox 10y ago

WAVM https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM Which has some nice capabilities such as the ability to call functions with arguments from the command line wavm ../Test/spec/fac.wast --function fac-iter 5 stdin/stderr/stdout is also supported for pure command line applications all while being sandboxed.

tsavola 10y ago

Here's mine (although it's not an interpreter): https://github.com/tsavola/wag https://github.com/tsavola/wag