5 ms·

It's just a binary encoding of the AST. Nothing more, nothing less. It's not quite a bytecode, those are typically for interpreters. Binary encoding would be

by bcheung 11y ago

It's just a binary encoding of the AST. Nothing more, nothing less. It's not quite a bytecode, those are typically for interpreters. Binary encoding would be more accurate. The semantics will be identical to JavaScript but the syntax obviously can be completely different depending on the language.

TazeTSchnitzel 11y ago
It's a binary encoding of a WebAssembly AST. It's not JavaScript, though it lives in the same universe.
- bcheung 11y ago
  That's exactly what I said. Why did I get downvoted?
  - TazeTSchnitzel 11y ago
    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.
    - bcheung 11y ago
      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.md 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)."
    - ZenoArrow 11y ago
      > "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.
      - TazeTSchnitzel 11y ago
        > 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.
        ZenoArrow 11y ago
        > "No, you can't. You don't have all the type information needed." https://github.com/toshok/echojs https://github.com/toshok/echojs
        vmorgulis 11y ago
        "I want to play around with what is essentially profile guided optimization, but with runtime type information. So you get a partially specialized (at least as much as the static compilation can give you) implementation, which then records type information at runtime." Very advanced optimizations. Emscripten doesn't do that (not yet, but LLVM has PGO).
        TazeTSchnitzel 11y ago
        I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.
  - ZenoArrow 11y ago
    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.

by bcheung 11y ago

TazeTSchnitzel 11y ago

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

bcheung 11y ago
That's exactly what I said. Why did I get downvoted?
- TazeTSchnitzel 11y ago
  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.
  - bcheung 11y ago
    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.md 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)."
  - ZenoArrow 11y ago
    > "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.
    - TazeTSchnitzel 11y ago
      > 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.
      - ZenoArrow 11y ago
        > "No, you can't. You don't have all the type information needed." https://github.com/toshok/echojs https://github.com/toshok/echojs
        vmorgulis 11y ago
        "I want to play around with what is essentially profile guided optimization, but with runtime type information. So you get a partially specialized (at least as much as the static compilation can give you) implementation, which then records type information at runtime." Very advanced optimizations. Emscripten doesn't do that (not yet, but LLVM has PGO).
        TazeTSchnitzel 11y ago
        I've done something similar for PHP before. But what you get is code that essentially embeds a dynamic language runtime into your code in the places where the types aren't known. It's less efficient than JIT compilation.
- ZenoArrow 11y ago
  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.