4 ms·

Do they have a different bytecode and runtime from WASM? Why not unify everything to web assembly byte code?

pizlonator 7y ago
They are different. Unifying is not a bad idea.
ori_b 7y ago
WASM byte code is structured into a tree, which means an interpreter loop wouldn't perform well. You'd really want to flatten it into a simpler bytecode before interpreting it -- and you'd want to do other transforms on it before optimizing it. I don't think WASM bytecode is a good format for execution, and it's only mediocre as a compilation target.
- riotman 7y ago
  Then why not abandon wasm, and make this byte code a target for llvm?
  - ori_b 7y ago
    LLVM bitcode is CPU and ABI dependent, and isn't even stable between LLVM releases.
    - riotman 7y ago
      Bad question on my part. More relevant: Why wasm? From what I gather, js seems to already have a bytecode for their JIT runtime. Why not expose that so that we can have C++ in the web?
      - singularity2001 7y ago
        I asked the same question, see below for interesting thread
        riotman 7y ago
        sigh I think the modern web was a mistake from hacks of the 90s to share documents. Can we plz get a fresh restart from scratch?
      - floatboth 7y ago
        > js seems to already have a bytecode for their JIT runtime This is kind of a nonsensical statement. JS itself doesn't have a bytecode, it's just a specification of the language you write scripts in. Each implementation has its own intermediate representations, including bytecode formats. WASM is a vendor-neutral standard that is designed as a compilation target and designed with safety in mind. SpiderMonkey/JSC/V8 internal bytecode formats are just that, compiler internals.
  - saagarjha 7y ago
    This isn’t a standard.
- mark_edward 7y ago
  This doesn't make any sense as an objection to me. If it's difficult to execute because it's a tree, then flatten that tree into a list of executable modules using pre-order traversal and name-mangling, what's the big deal?

They are different. Unifying is not a bad idea.

WASM byte code is structured into a tree, which means an interpreter loop wouldn't perform well. You'd really want to flatten it into a simpler bytecode before interpreting it -- and you'd want to do other transforms on it before optimizing it. I don't think WASM bytecode is a good format for execution, and it's only mediocre as a compilation target.

riotman 7y ago
Then why not abandon wasm, and make this byte code a target for llvm?
- ori_b 7y ago
  LLVM bitcode is CPU and ABI dependent, and isn't even stable between LLVM releases.
  - riotman 7y ago
    Bad question on my part. More relevant: Why wasm? From what I gather, js seems to already have a bytecode for their JIT runtime. Why not expose that so that we can have C++ in the web?
    - singularity2001 7y ago
      I asked the same question, see below for interesting thread
      - riotman 7y ago
        sigh I think the modern web was a mistake from hacks of the 90s to share documents. Can we plz get a fresh restart from scratch?
    - floatboth 7y ago
      > js seems to already have a bytecode for their JIT runtime This is kind of a nonsensical statement. JS itself doesn't have a bytecode, it's just a specification of the language you write scripts in. Each implementation has its own intermediate representations, including bytecode formats. WASM is a vendor-neutral standard that is designed as a compilation target and designed with safety in mind. SpiderMonkey/JSC/V8 internal bytecode formats are just that, compiler internals.
- saagarjha 7y ago
  This isn’t a standard.
mark_edward 7y ago
This doesn't make any sense as an objection to me. If it's difficult to execute because it's a tree, then flatten that tree into a list of executable modules using pre-order traversal and name-mangling, what's the big deal?