binji

This is an interesting article, and mirrors my experience of porting. I really loved seeing the advice from various other developers he consulted. It's a nice way to expand it from being just his experience to a more general statement about what it's like to port software. I never ported a commercial game, but did quite a bit of porting to Native Client. The parts about knowing your tools, knowing the project, and the process of porting are spot on.

One thing he didn't mention (or I missed it), is how it feels when your port starts to work. I found it to be thrilling to have a big pile of code that doesn't work at all, and it stays that way for a while, until suddenly almost everything seems to come together. It's very different from normal software development, which is more gradual. Porting software feels more like solving a puzzle.

As sunfish mentions below, this spec document is being conservative in describing things that are still being discussed.

There are experimental implementations in Firefox, Chrome and Edge. See https://webassembly.github.io/demo/.

There's more information about the current binary format here: https://github.com/WebAssembly/design/blob/master/BinaryEnco...

There's a prototype spec interpreter here: https://github.com/WebAssembly/spec/tree/master/ml-proto

There's a build waterfall testing multiple tools here: https://wasm-stat.us/console, including the experimental LLVM toolchain, the emscripten-wasm toolchain[0], binaryen[1], and sexpr-wasm[2].

WebAssembly is still under development, but I don't think it's fair to call it an early prototype.

[disclaimer: I'm a WebAssembly contributor]

[0]: https://github.com/kripken/emscripten/wiki/WebAssembly

[1]: https://github.com/WebAssembly/binaryen

[2]: https://github.com/WebAssembly/sexpr-wasm-prototype/

I've made some progress on this, but there's still a way to go: https://github.com/WebAssembly/sexpr-wasm-prototype/commit/8...

Right, but it's worth mentioning that no part of WebAssembly is ready for general usage, as it is not yet released. :)

Just like other components of the technology preview, I think it would be useful to have interested developers try it out and give feedback in the form of bug reports -- understanding that things are incomplete and going to change.

We've been calling them modules, but I'm not certain that's what we'll end up with.

Also, there's a reason the description is a bit fuzzy on the WebAssembly landing page. It's not just a binary format (in fact, we didn't have a binary format for a while after we started). I like to think that it's a specification of execution semantics that can be expressed in many different formats (text, binary, AST, etc.). Not sure that's the easiest way to explain it though.

See my comment above, ultimately you should be able to generate WebAssembly directly from your C compiler (and other languages too). You can write it by hand as well, but that's not the primary goal of the specification.

We should have a text format soon too, which will be nicer than the AST format to read/write by hand.

Ultimately you should be able to use your C compiler and generate wasm files directly, rather than go through asm.js.

There is an experimental backend of LLVM that you can try, but it will require building LLVM from source currently. Emscripten has an option to do this automatically, I believe.

You can also write the AST format by hand, which IMO is much easier to do than writing asm.js by hand, just more verbose. I wouldn't advise anyone do this, as the format has been changing over time.

Finally, there is work on specifying a true "text format" that is meant to be used with view-source and directly maps to the binary format. You can see some proposals if you look at the pull requests in the design repo. When a proposal is accepted and we implement the tooling, you will be able to generate a binary directly from this format, which will be much nicer.

There's a response above this one from titzer describing it, or you can read more here: https://github.com/WebAssembly/design/blob/master/DynamicLin...

ARC (https://developer.chrome.com/apps/getstarted_arc)

I ported this to Lua as a PNaCl demo: https://gonativeclient.appspot.com/demo/lua

Click the "Donut" button, and press enter.

You can run a port of SmoothLife in Chrome (via PNaCl) here: http://gonativeclient.appspot.com/demo/smoothlife

Ah, thanks for that! I was wondering if repl.it was out of date. Might be worthwhile to get the owner to update... :)

We were seeing some significant slowdowns when running lua in emscripten (testing on repl.it) vs. PNaCl.

Take this naive fibonacci function: function fib(n) return n<2 and n or fib(n-1)+fib(n-2) end print(fib(30))

On my machine, it completes in less than a second on PNaCl, but takes nearly 10 seconds to complete in emscripten.

They can all be done in JS (modified to remove threading, of course). In fact, many of them already run in emscripten/pepper.js (see http://trypepperjs.appspot.com).