Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skeleton WebAssembly target

reviews.llvm.org

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Skeleton WebAssembly target

#41

Post by TazeTSchnitzel »

bcheung wrote: post #39
TazeTSchnitzel wrote: post #34

Earlier quoted context omitted.

It's a binary encoding of a WebAssembly AST. It's not JavaScript, though it lives in the same universe.

That's exactly what I said. Why did I get downvoted?

Because your comment is misleading or inaccurate. The comment you had replied to was completely correct.

> It's just a binary encoding of the AST. Nothing more, nothing less.

No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST.

> It's not quite a bytecode, those are typically for interpreters.

It is a bytecode, by any normal meaning of the term. WebAssembly could be interpreted, or could be AOT compiled.

Re: Skeleton WebAssembly target

#42

Post by TazeTSchnitzel »

lucozade wrote: post #18
atonse wrote: post #3

Earlier quoted context omitted.

Yes, LLVM has two tiers, a front end, and a back end (someone else correct me if i butcher concepts or names): The front end basically converts your human readable code to LLVM intermediate byte code (called IR, or intermediate representation). The byte code is independent of a CPU or programming language. A second stage then turns that IR into x86 code or ARM code, etc. (these are "targets"). In this case, they adde…

Just a couple of clarifications. Although the LLVM IR is mostly agnostic to the target, in practice, it's not quite that simple. However, the IR layer does make it substantially easier to move between languages and targets. It's just not free. Also, my understanding is that WebAssembly isn't a JS thing. The intent is that a VM for the bytecode will be added to the browsers alongside the JS engine. In the short term t…

> Also, my understanding is that WebAssembly isn't a JS thing.

Not really. WebAssembly is not entirely unlike asm.js. It will live within the same world that JavaScript does.

Re: Skeleton WebAssembly target

#43

Post by ZenoArrow »

bcheung wrote: post #39
TazeTSchnitzel wrote: post #34

Earlier quoted context omitted.

It's a binary encoding of a WebAssembly AST. It's not JavaScript, though it lives in the same universe.

That's exactly what I said. Why did I get downvoted?

This is my basic understanding...

Consider the interpreters written to run JavaScript. They create ASTs in order to run it. WebAssembly should allow you to target the AST layer directly. The JS compatibility is a fallback. In order to have this fallback, the AST will be similar to that which is used for asm.js.

Furthermore, whilst it's sensible to design WebAssembly with compatibility in mind at first, there's no reason why future versions of WebAssembly can't drop support for JS altogether (whether that'll happen or not remains to be seen). So long as WebAssembly v1 supports a JS fallback, then WebAssembly v2 (or whatever it's called) need not, so long as v1 is kept around. We're talking probably a decade away (if at all) but as far as I can see the end goal is a high-performance, language-neutral web, and JS fallback is just a stepping stone towards that goal. I'm sure JS will stick around on the web regardless.

Re: Skeleton WebAssembly target

#44

Post by bcheung »

TazeTSchnitzel wrote: post #41
bcheung wrote: post #39

Earlier quoted context omitted.

That's exactly what I said. Why did I get downvoted?

Because your comment is misleading or inaccurate. The comment you had replied to was completely correct. > It's just a binary encoding of the AST. Nothing more, nothing less. No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST. > It's not quite a bytecode, those are typically for interpreters. It is a bytecode, by any normal meaning of the term. WebAssembly cou…

You're right, I could have been clearer about saying it is a new AST and not a JavaScript/asm.js AST. That is what I meant.

Bytecodes are for instruction sets, not trees though.

From wikipedia, "Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter."

There are no instructions to interpret since there is no instruction set defined. It is possible though that certain browsers may take the AST and create an instruction set for an interpreter or they may compile it to native code but that is entirely browser specific and has nothing to do with WebAssembly.

https://github.com/WebAssembly/design/blob/master/TextFormat...

"Given that the code representation is actually an Abstract Syntax Tree, the syntax would contain nested statements and expressions (instead of the linear list of instructions most assembly languages have)."

Re: Skeleton WebAssembly target

#45

Post by sunfish »

TazeTSchnitzel wrote: post #35
cpeterso wrote: post #31

Earlier quoted context omitted.

Will there be any advantage to generating asm.js over WebAssembly+polyfill for clients that don't support WebAssembly natively?

The polyfill is slower.

The polyfill generates essentially the same asm.js code, so it runs at a similar speed. The slowdown is a translation delay at startup.

On the other hand, WebAssembly code is smaller than asm.js code, so it downloads faster, so in some situations the polyfill is actually faster.

Re: Skeleton WebAssembly target

#46

Post by ZenoArrow »

TazeTSchnitzel wrote: post #41
bcheung wrote: post #39

Earlier quoted context omitted.

That's exactly what I said. Why did I get downvoted?

Because your comment is misleading or inaccurate. The comment you had replied to was completely correct. > It's just a binary encoding of the AST. Nothing more, nothing less. No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST. > It's not quite a bytecode, those are typically for interpreters. It is a bytecode, by any normal meaning of the term. WebAssembly cou…

> "No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST."

From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.

> "WebAssembly could be interpreted, or could be AOT compiled."

You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distribution method and in better use of hardware (low-overhead threads, etc...). That said, there's certainly plenty of potential for WebAssembly to leave other restrictions behind.

Re: Skeleton WebAssembly target

#47

Post by kayamon »

TazeTSchnitzel wrote: post #36
echeese wrote: post #23

Earlier quoted context omitted.

Are there any examples of the text format of wasm?

It doesn't yet exist. The specifications haven't been written, these are high-level design documents.

Based on the spec so far, there's a very good chance it'll look _almost exactly like asm.js_

Re: Skeleton WebAssembly target

#48

Post by TazeTSchnitzel »

ZenoArrow wrote: post #46
TazeTSchnitzel wrote: post #41

Earlier quoted context omitted.

Because your comment is misleading or inaccurate. The comment you had replied to was completely correct. > It's just a binary encoding of the AST. Nothing more, nothing less. No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST. > It's not quite a bytecode, those are typically for interpreters. It is a bytecode, by any normal meaning of the term. WebAssembly cou…

> "No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST." From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks. > "WebAssembly could be interpreted, or could be AOT compiled." You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distri…

> From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks.

At least initially it'll be similar to asm.js, yes.

> You can do AOT compilation of JS too.

No, you can't. You don't have all the type information needed.

Re: Skeleton WebAssembly target

#49

Post by ZenoArrow »

TazeTSchnitzel wrote: post #48
ZenoArrow wrote: post #46

Earlier quoted context omitted.

> "No, it is not a binary encoding of the JavaScript/asm.js AST. It is a binary encoding of the WebAssembly AST." From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks. > "WebAssembly could be interpreted, or could be AOT compiled." You can do AOT compilation of JS too. The initial benefits of WebAssembly appear to come from in the binary distri…

> From what I understand, WebAssembly ASTs will be very similar structurally to asm.js ASTs in order to permit easy JS fallbacks. At least initially it'll be similar to asm.js, yes. > You can do AOT compilation of JS too. No, you can't. You don't have all the type information needed.

> "No, you can't. You don't have all the type information needed."

https://github.com/toshok/echojs

Re: Skeleton WebAssembly target

#50

Post by vmorgulis »

bcheung wrote: post #29
andybak wrote: post #10

If webassembly is essentially asm.js directly converted to a more compact bytecode format but with the same semantics - and emscripten already provides llvm with a backend that outputs asm.js, then what's significant about this? I had assumed from the original webassembly announcement that this would be a fairly trivial step but I expect I've misunderstood something.

WebAssembly itself doesn't have anything to do with asm.js near as I can tell. It's more the ecosystem surrounding WebAssembly. I looked through the specs a little bit. What it is, is a binary encoding of the AST with some optimizations thrown in to decrease size (symbol tables instead of using the full tokens). I'm unclear on why asm.js is even mentioned but I suspect it is a temporary stop gap since those languages…

It will add a new dimension to web development.
Post reply on HN