5 ms·

My understanding is that it will only initially mirror asm.js but will eventually become a full-blown, independent bytecode IR that departs from JavaScript sema

My understanding is that it will only initially mirror asm.js but will eventually become a full-blown, independent bytecode IR that departs from JavaScript semantics (while continuing to support expressing them), allowing other languages to be compiled down to WebAssembly and run in the browser efficiently. Having a bytecode format also eases the considerable burden of parsing JavaScript – which is especially problematic on constrained devices like mobile phones.

jashkenas 11y ago
Got some Julia plans or hopes?
- StefanKarpinski 11y ago
  Sure – with a first-class LLVM backend for WebAssembly, we could absolutely compile to it, which would mean running fully in the browser, which is something Emscripten can't quite manage at this point. That would certainly be very cool (and useful too). See https://github.com/JuliaLang/julia/issues/9430 https://github.com/JuliaLang/julia/issues/9430.
cordite 11y ago
There's already ASICs for Lua and other to-simplistic-bytecode out there for low power applications (If I recall correctly anyway with tessel.) What's to say when these things are settled, we are left with something that handles asynchrony well and it becomes the basis for IoT?
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.

jashkenas 11y ago

Got some Julia plans or hopes?

StefanKarpinski 11y ago
Sure – with a first-class LLVM backend for WebAssembly, we could absolutely compile to it, which would mean running fully in the browser, which is something Emscripten can't quite manage at this point. That would certainly be very cool (and useful too). See https://github.com/JuliaLang/julia/issues/9430 https://github.com/JuliaLang/julia/issues/9430.

cordite 11y ago

There's already ASICs for Lua and other to-simplistic-bytecode out there for low power applications (If I recall correctly anyway with tessel.) What's to say when these things are settled, we are left with something that handles asynchrony well and it becomes the basis for IoT?

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.