Open svaarala opened 7 years ago
I was under the impression that WebAssembly was just a subset of full JavaScript. Is that not actually the case?
You might be thinking of asm.js - webassembly provides a binary bytecode format, a Javascript API for it, etc.
The wasm stack machine is designed to be encoded in a size- and load-time-efficient binary format.
There's a textual format, but it's for debugging etc (http://webassembly.org/docs/text-format/), example:
get_local 0
i64.const 0
i64.eq
if i64
i64.const 1
else
get_local 0
get_local 0
i64.const 1
i64.sub
call 0
i64.mul
end
The intent is to be able to compile e.g. a C program directly to WebAssembly binary format, and then execute from there.
Yeah, asm.js was what I was thinking of. WebAssembly seems interesting: what I got out of that page was that it's essentially an attempt at a standardized bytecode format for JS, mainly this part:
WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines.
That's a really nice idea. Even something like miniSphere could benefit from it. :)
It's not for JS, but a pretty different language - it's best explained by looking at the bytecode format and what operations it supports.
Would be interesting to see how a javascript to wasm compiled program competes against duktape (both without JIT) ;)
FWIW, I've recently added WebAssembly parse + execute support to a project of mine called VMIR.
Don't want to hijack this thread but more info can be found on its GitHub page: https://github.com/andoma/vmir
@andoma Thanks, looks interesting! It should be possible to use VMIR for loosely coupling a WebAssembly executor to Duktape, as long as the WebAssembly <-> Javascript transition works well enough.
Would it be possible for you to share the c progam(s) / emscripten makefile that you used to produce dukweb.js that is used on your browser repl?
I am interested in creating a web assembly version of this repl. Or maybe you have already done this?
Thanks
All the stuff is in the main repo:
Let me know how it goes, would be nice to know how that works out :)
Thanks @svaarala ... I created a test of the WebAssembly version here ... https://s3.amazonaws.com/mparsons/dukweb/index.html
It is considerably faster than the Javascript version and is pretty close to native speed :-)
Just add -s EXTRA_EXPORTED_RUNTIME_METHODS="['cwrap','ccall']" -s WASM=1 to your make file.
Thanks so much for this incredible library :-)
@mikeptweet Awesome, I'll add that to the Makefile too :)
Anybody worked on something yet? WAVM and wasmjit only work on 64bit CPU, while the big JS engines (SpiderMonkey, v8, ChakraCore, JavaScriptCore) probably work on 32/64bit CPU's each.
I guess the best would be to just rip out one WASM implementation of these four engines and write Duktape bindings for it?
I don't see a good way yet to bring WebAssembly into small software projects, without bloating them up with one of those four giant JS engines. Duktape+WASM would be kinda perfect.
Duktape+WASM would be kinda perfect.
I think Wasm3 is now stable enough to be integrated with Duktape: https://github.com/wasm3/wasm3
Any updates on this?
WebAssembly is now stable enough to be implemented: https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html.
There are several options for Duktape to interact with WebAssembly; two main approaches are:
Regardless of the coupling approach, providing optional JIT or direct code generation would be useful for WebAssembly. It's a smaller problem than a Javascript JIT, and could help with implementing e.g. numerical algorithms in a portable manner.