design

In case you're not aware, I believe that web assembly is a stack based language. You may be interested to read this, which talks about a proposal to add additional stack instructions: https://github.com/WebAssembly/design/issues/1381

Hopefully a few years/decades from now, we will be remembering the day WebAssembly was announced. [1] 1: https://github.com/WebAssembly/design/issues/150

Agreed that the WebAssembly spec is a pain to read. I mostly used this outdated doc: https://github.com/WebAssembly/design/blob/master/BinaryEnco... Generating C seems like a good middle ground. I also considered that. Frankly though code generation is hard regardless because you’re gonna have some abstractions that just don’t lower nicely. Writing the runtime in Rust might work but ownership might get in the way. Happy to talk about this more if you want. Shoot me an email

Huh, I didn't know this was the case for WebAssembly. I found a discussion about it amongst the WebAssembly designers. https://github.com/WebAssembly/design/issues/204 -- Looks like efficient implementation of mprotect() was a sticking point, and its been relegated to a Future Feature https://github.com/WebAssembly/design/blob/master/FutureFeat...

no, I'm talking about this [0] does support for socket(udp and tcp)? [1] encountered with problem when Porting UDP socket communication c code using emscripten one example among other, and so you can use WebAssembly all you want you will never be able to implement flash.net.DatagramSocket [0]: https://github.com/WebAssembly/design/issues/1251 [1]: https://github.com/emscripten-core/emscripten/issues/5196

WebAssembly allows deterministic execution (with caveats: https://github.com/WebAssembly/design/blob/master/Nondetermi...) of any code. I think it is a perfect platform for such type of testing.

I would still consider WASM a stack machine and not a register machine. Yes, there are mutable local variables in WASM but Java bytecode has them as well - which you consider a stack machine. BTW the designers of WASM explicitly call WASM a stack machine here: https://github.com/WebAssembly/design/blob/master/Rationale..... With WASM's MVP it was necessary to store e.g. loop state in local variables, thanks to recent changes this doesn't seem to be necessary anymore. I think this was the main argument that blog post considered WASM to be a register machine. javac also makes heavy use of variables in bytecode, but somehow no one considers the JVM a register machine. > my observations are that people with experience in the field tend to prefer register machines That's actually the opposite of my observation, they seem to prefer stack machin

I don't think that's true. It was designed for its purpose by people that knew what they were doing based on experience gathered from implementing previous incremental steps including emscripten's original JavaScript output and asm.js (a formalization of some techniques emscripten employed). The design rationale is right there in the spec repository: https://github.com/WebAssembly/design/blob/master/Rationale.... It was built to be a better target than asm.js for compiled languages to run in JavaScript VMs and it seems to have succeeded on that front. That it's not a perfect fully-general bytecode format doesn't seem like a real knock against it, that's a much harder problem to solve. In any event it seems to be getting a lot more traction than any previous entries in the space, which is exciting!

As context, at the time of those issues, the control-flow restrictions were a compromise to help get the "MVP" off the ground, with the understanding that "more expressive control flow" was expected to be added later: https://github.com/WebAssembly/design/blob/master/FutureFeat...

It's bizarre to me that there are complaints about the if-else bytecodes. You can call them "weird" but they're very easy to reason about, make it easy to write toy examples, are easier to generate from a compiler, and are easier to read and understand in disassembly. At the point where the author started talking about customized compression to recover the size gains they should have realized why the bytecodes exist! Early on in the spec process it was very, very useful to have them. Anyone questioning whether the lack of goto was the result of an invocation of veto power can look at the design repo and see that lots of control flow consideration and discussion happened in the open before the group finally agreed upon a solution. Many of the players involved were not Google employees at the time of the decision (I don't know if they are n

A lot of those bad WebAssembly decisions are carried over from Emscripten/Asm.js and don't have any real rationale behind them beyond that. Obviously, since JS doesn't support arbitrary control flow, Emscripten/Asm.js would need to convert to some simplified form of control flow (although not necessarily fully structured). It seems that this solution was carried over to WebAssembly without much deep thought given. There does seem to be some backwards association with Java's bytecode verification complexity issues (which are the result of a bad design, not unstructured control flow). In the big GitHub Issue (https://github.com/WebAssembly/design/issues/796) on the topic, one of the core V8 developers even claims that the Java experience justifies the WebAssembly decision. However, the funclets proposal for WebAssembly (https://github.com/W