Live data from Hacker News

WebAssembly Stack Machine

docs.google.com

41–47 of 47 posts

Re: WebAssembly Stack Machine

#41
post #15
post #4

The WA stack machine was added late in the game. Before that it was an AST but they got pushback from browser backend people and pivoted to a stack machine. https://github.com/WebAssembly/design/issues/755 AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. This is a bad decision (stacks vs AST or register) made for the wrong reason (code s…

I've implemented the stack-machine validation rules, and they're very similar to the postorder AST validation rules. In some areas, they're actually simpler, because the stack-machine rules accept roughly a superset of the AST rules, so there are fewer constraints to enforce. The stack-machine rules were indeed added late, and it's reasonable to ask whether they might have been improved if there had been more time to…

It also great for obfuscation.

PS.

I am talking about problem of trust, which this binary format creates. Here, in Linux, we are solving problem of trust using distributions, maintainers, signed packages, signed repositories, releases. It's why I will trust binary packages from my distribution but will not trust webasm binaries.

Re: WebAssembly Stack Machine

#42
post #28

Earlier quoted context omitted.

There is already PyPy.js using asm.js, doppiojvm which is written in JavaScript, and some effort on getting OpenJDK and/or JamVM to work on asm.js. I don't think you'll have to wait 5 years.

I imagine people will use it on the desktop apps and soon everything will just be running with WASM! It sounds like it has the potential to unify web development with development on all platforms if it is efficient enough. EDIT: I didn't think I would be excited about WebAssembly but I'm now really curious to see what happens with it.

the browser is a game engine with beefed up security, to quote servo. webassembly is the end game of scriptability of that engine.

what you say about app development being unified is already true: see atom, steam and all others who embed webkit or similar to create a desktop UI.

Re: WebAssembly Stack Machine

#43
post #41
post #15

Earlier quoted context omitted.

I've implemented the stack-machine validation rules, and they're very similar to the postorder AST validation rules. In some areas, they're actually simpler, because the stack-machine rules accept roughly a superset of the AST rules, so there are fewer constraints to enforce. The stack-machine rules were indeed added late, and it's reasonable to ask whether they might have been improved if there had been more time to…

It also great for obfuscation. PS. I am talking about problem of trust, which this binary format creates. Here, in Linux, we are solving problem of trust using distributions, maintainers, signed packages, signed repositories, releases. It's why I will trust binary packages from my distribution but will not trust webasm binaries.

Instead of having everything go through central trusted authorities, as Linux distros do, wasm (as the Web does in general) relies on sandboxing untrusted content on the user side.

A binary encoding does not contribute significantly to obfuscation when it can be trivially undone. WebAssembly is an open standard, and browsers supporting wasm have builtin support for converting it to text and displaying it.

Compiled code can be much harder to read than human-written code, though this is mainly because of lowering and optimization, rather than the final encoding.

Re: WebAssembly Stack Machine

#44

Earlier quoted context omitted.

> AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. Why? This document suggests that it's not that different. "The main new changes to verification are: - All branches to the end of a block must have the same arity and same types, including the implicit fall-through to end. - The true block of if-end constructs must leave the stack at the…

constructs must leave the stack at the same height with the same types That's easy to 'document' and harder to do. It's what the JVM did, again, in the 90s. Now the verifier chapter in the JVM spec is now about 160 pages long.

We learned our lessons from the JVM, and the verification algorithm for WASM is vastly simpler. It's even been formalized and fits in about 3/4 a page.

Re: WebAssembly Stack Machine

#45
I believe that switching to a stack machine is short-sighted and a big mistake:

The AST format could open up new possibilities for software, some of which are observable in Lispy languages like Scheme (I won't list them here). Instead, we're looking at locking the software world back into this 1960's model for another 50 years out of a misguided concern for optimization over power.

It's like foregoing the arch because it's more work to craft, and instead coming up with a REALLY efficient way to fit square blocks together. Congratulations, we can build better pyramids, but will never grasp the concept of a cathedral.

To really grasp my point, I BEG you all to watch the following two videos in full and think hard about what Alan Kay & Douglass Crockford have to say about new ideas, building complex structures, and leaving something better for the next generation:

https://youtu.be/oKg1hTOQXoY

https://www.youtube.com/watch?v=PSGEjv3Tqo0

As Alan Kay states, what is simpler: something that's easier to process, but for which the software written on top of it is massive; or one that takes a bit more overhead, but allows for powerful new ways to model software and reduce complexity?

I believe that an AST model is a major start in inventing "the arch" that's been missing in software, and with something that will proliferate the whole web ... how short-sighted it would be to give that up in favor of "optimizing" the old thing.

Imagine if instead of JavaScript, the language of the web had been Java? Lambdas would not be mainstream; new ways of doing OOP would not be thought of; and all the amazing libraries that have been written because of the ad-hoc object modeling that JavaScript offers. Probably one of the messiest and inefficient languages ever written, yet one of the most powerful ever given. C'mon, let's do it a step more by making it binary, homoiconic, and self-modifying.

Thanks.

Re: WebAssembly Stack Machine

#46

I believe that switching to a stack machine is short-sighted and a big mistake: The AST format could open up new possibilities for software, some of which are observable in Lispy languages like Scheme (I won't list them here). Instead, we're looking at locking the software world back into this 1960's model for another 50 years out of a misguided concern for optimization over power. It's like foregoing the arch becaus…

...and if you're brave enough, think about how Christopher Alexander's philosophy of "unfolding wholeness" applies so much more to an AST than to the stack-machines of the 1960's:

https://youtu.be/98LdFA-_zfA

Re: WebAssembly Stack Machine

#47
post #43
post #41

Earlier quoted context omitted.

It also great for obfuscation. PS. I am talking about problem of trust, which this binary format creates. Here, in Linux, we are solving problem of trust using distributions, maintainers, signed packages, signed repositories, releases. It's why I will trust binary packages from my distribution but will not trust webasm binaries.

Instead of having everything go through central trusted authorities, as Linux distros do, wasm (as the Web does in general) relies on sandboxing untrusted content on the user side. A binary encoding does not contribute significantly to obfuscation when it can be trivially undone. WebAssembly is an open standard, and browsers supporting wasm have builtin support for converting it to text and displaying it. Compiled co…

It's looks like you have very limited experience with Linux distros. Nobody forces Linux users to use repositories. We use repositories because we trust them much more than random binary blobs from Internet. Binary encoding contribute significantly to obfuscation, because it cannot be formatted, or refactored, or commented, or modified (e.g. to add assertion or print debugging information). Nobody programs in binary.

WebAsm creates problem. Same problem as Java, Flash, Unity, PNaCl and dozens of other platforms to execute binary blobs from untrusted sources. And the only solution is to add trust, e.g. by publishing heavy-weight libraries for review and patching by third-party maintainers, e.g. such libraries as SDL, game engines, GUI, databases, etc. Otherwise, we will have same situation as with other libraries, e.g. JQuery, when sites are using old version of common library with known security problems for ages, despite that fixed version is freely available.

Post reply on HN