5 ms·

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about w

by ryacko 7y ago

"We could break the stranglehold of i386 on the software industry and free developers to experiment with novel CPU architectures without having to worry about whether our favorite language compiles to it." WASM is equivalent to early 80s ISAs but with different opcodes. Native WASM would be most efficient.

mises 7y ago
Literally the whole point of WASM is fast, sandboxed code. It's not a language, it's an LLVM target. So why turn LLVM IR into a native binary? It's basically the same thing as "native wasm", whatever that would mean. "Native wasm" is just JITed bytecode. Either that, or you're turning it into a normal binary, in which case, why even use WASM?
- bane 7y ago
  https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
- ryacko 7y ago
  x86 is translated to micro-ops in the processor. Why use x86 if you don't need a half-carry flag?
- _nhynes 7y ago
  You get a bit of safety because Wasm programs have statically validated function calls and operate only within linear memory. If there are no bugs in the stdlib or the bytecode compiler, then the host is still sandboxed from the module even without virtual memory.
  - lightgreen 7y ago
    No, it’s not possible to statically validate that addresses are within linear memory. WebAssembly implementations do runtime memory access checks (either with explicit if checks before some loads and stores or with virtual memory configuration).
    - saagarjha 7y ago
      > it’s not possible to statically validate that addresses are within linear memory It might just be me, but I don't think this is what the parent comment said.
      - lightgreen 7y ago
        “Statically validated” AFAIU means there are no runtime checks. E. g. WASM stack local variables and globals are statically validated. Compiler can translate loads and stores to locals and globals to simple movs. There are no additional runtime checks, no overhead. Unlike linear memory.
        saagarjha 7y ago
        As far as I could parse that comment, it's saying that function calls are statically validated and that memory is linear. Not that all memory accesses can be statically validated.
        lightgreen 7y ago
        Fair point, author indeed said that function calls are statically validated, but did not say linear memory access is statically validated. This phrase “host is still sandboxed from the module even without virtual memory” confused me. Because technically any interpreter (even qemu) can run without virtual memory with more or less expensive runtime checks.
        writepub 7y ago
        Given WASM's 32 bit address space, you can effectively validate a programs memory access statically, with a one time initialization in virtual memory - for instance if you'd like to restrict all WASM memory to 64MB, you can allocate/map it to the top of a 4GB virtual address space, effectively giving it a start address of 4GB-64MB. Since OS/process virtual memory bound checking is handled by the hardware, the one time setup above will lock down WASM memory access to within the 64MB, without software runtime overheads. This is exactly why WASM memory was picked to be linear (unlike virtual memory that can have holes in continuity)
- hackerpacker 7y ago
  " It's not a language" It sure looks like a language to me, like some sort of assembly language. https://webassembly.org/getting-started/advanced-tools/ https://webassembly.org/getting-started/advanced-tools/ https://developer.mozilla.org/en-US/docs/WebAssembly/Text_format_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo... granted this is a textual representation (very useful in certain circumstances) but that is semantics. Having done plenty of assembly, I don't see a huge distinction here.
- WAHa_06x36 7y ago
  LLVM IR is not architecture-independent. It encodes architecture and ABI assumptions, and is not portable. Also, this is not "JITed bytecode", it is compiled AOT.
  - pjmlp 7y ago
    The PNaCL and Apple's variants are architecture independent.
    - WAHa_06x36 7y ago
      Well. They pick an architecture and stick with it, more like. But one is dead in favour of WebAssembly and the other is an internal format.
      - pjmlp 7y ago
        It doesn't change the fact that they do exist. PNaCL died in favour of WebAssembly due to politics. With Chrome today's might, the decision would most likely be a different one.
FullyFunctional 7y ago
I used to resort to binary translation for experimental CPU projects, but WASM looks like a much better starting point. The controversial lack of arbitrary control flow is a massive advantage for me. Writing an complete compiler backend/asm/ld is a significant undertaking which is only worthwhile for very stable architectures.
nullwasamistake 7y ago
Java Bytecode is similar to WASM, opcode wise. Bytecode purposely omits many instructions that can be done with equivalents to fit the whole ISA in single byte instructions. WASM is similar for the same reason, code density. The main difference in Bytecode/WASM is memory model and branching support. But you could say that both are equivalent to 80's ISA's. Precompiled Java is closer to WASM than many would like to admit, so I expect performance to be similar in the long run. This isn't so bad, Java reaches over half native speed on many benchmarks. It's amazing that we'll be able to run untrusted code so quickly
scriptproof 7y ago
You can avoid the effort to use the uppercase key and write wasm (or Wasm), that is the correct typography. Asm in wasm is acronym for nothing.
- mises 7y ago
  Asm for Assembly, so maybe WAsm is correct?
imtringued 7y ago
Not it wouldn't be because most bytecodes generally operate at a higher level. A single java call instruction can in theory turn into an unbounded number of machine instructions through inlining. Therefore limiting the machine to only executing entire java instructions will make it extremely slow because it cannot use any optimizations.

by ryacko 7y ago

mises 7y ago

Literally the whole point of WASM is fast, sandboxed code. It's not a language, it's an LLVM target. So why turn LLVM IR into a native binary? It's basically the same thing as "native wasm", whatever that would mean. "Native wasm" is just JITed bytecode. Either that, or you're turning it into a normal binary, in which case, why even use WASM?

bane 7y ago
https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
ryacko 7y ago
x86 is translated to micro-ops in the processor. Why use x86 if you don't need a half-carry flag?
_nhynes 7y ago
You get a bit of safety because Wasm programs have statically validated function calls and operate only within linear memory. If there are no bugs in the stdlib or the bytecode compiler, then the host is still sandboxed from the module even without virtual memory.
- lightgreen 7y ago
  No, it’s not possible to statically validate that addresses are within linear memory. WebAssembly implementations do runtime memory access checks (either with explicit if checks before some loads and stores or with virtual memory configuration).
  - saagarjha 7y ago
    > it’s not possible to statically validate that addresses are within linear memory It might just be me, but I don't think this is what the parent comment said.
    - lightgreen 7y ago
      “Statically validated” AFAIU means there are no runtime checks. E. g. WASM stack local variables and globals are statically validated. Compiler can translate loads and stores to locals and globals to simple movs. There are no additional runtime checks, no overhead. Unlike linear memory.
      - saagarjha 7y ago
        As far as I could parse that comment, it's saying that function calls are statically validated and that memory is linear. Not that all memory accesses can be statically validated.
        lightgreen 7y ago
        Fair point, author indeed said that function calls are statically validated, but did not say linear memory access is statically validated. This phrase “host is still sandboxed from the module even without virtual memory” confused me. Because technically any interpreter (even qemu) can run without virtual memory with more or less expensive runtime checks.
        writepub 7y ago
        Given WASM's 32 bit address space, you can effectively validate a programs memory access statically, with a one time initialization in virtual memory - for instance if you'd like to restrict all WASM memory to 64MB, you can allocate/map it to the top of a 4GB virtual address space, effectively giving it a start address of 4GB-64MB. Since OS/process virtual memory bound checking is handled by the hardware, the one time setup above will lock down WASM memory access to within the 64MB, without software runtime overheads. This is exactly why WASM memory was picked to be linear (unlike virtual memory that can have holes in continuity)
hackerpacker 7y ago
" It's not a language" It sure looks like a language to me, like some sort of assembly language. https://webassembly.org/getting-started/advanced-tools/ https://webassembly.org/getting-started/advanced-tools/ https://developer.mozilla.org/en-US/docs/WebAssembly/Text_format_to_wasm https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo... granted this is a textual representation (very useful in certain circumstances) but that is semantics. Having done plenty of assembly, I don't see a huge distinction here.
WAHa_06x36 7y ago
LLVM IR is not architecture-independent. It encodes architecture and ABI assumptions, and is not portable. Also, this is not "JITed bytecode", it is compiled AOT.
- pjmlp 7y ago
  The PNaCL and Apple's variants are architecture independent.
  - WAHa_06x36 7y ago
    Well. They pick an architecture and stick with it, more like. But one is dead in favour of WebAssembly and the other is an internal format.
    - pjmlp 7y ago
      It doesn't change the fact that they do exist. PNaCL died in favour of WebAssembly due to politics. With Chrome today's might, the decision would most likely be a different one.

FullyFunctional 7y ago

I used to resort to binary translation for experimental CPU projects, but WASM looks like a much better starting point. The controversial lack of arbitrary control flow is a massive advantage for me. Writing an complete compiler backend/asm/ld is a significant undertaking which is only worthwhile for very stable architectures.

nullwasamistake 7y ago

Java Bytecode is similar to WASM, opcode wise. Bytecode purposely omits many instructions that can be done with equivalents to fit the whole ISA in single byte instructions. WASM is similar for the same reason, code density. The main difference in Bytecode/WASM is memory model and branching support. But you could say that both are equivalent to 80's ISA's. Precompiled Java is closer to WASM than many would like to admit, so I expect performance to be similar in the long run. This isn't so bad, Java reaches over half native speed on many benchmarks. It's amazing that we'll be able to run untrusted code so quickly

scriptproof 7y ago

You can avoid the effort to use the uppercase key and write wasm (or Wasm), that is the correct typography. Asm in wasm is acronym for nothing.

mises 7y ago
Asm for Assembly, so maybe WAsm is correct?

imtringued 7y ago

Not it wouldn't be because most bytecodes generally operate at a higher level. A single java call instruction can in theory turn into an unbounded number of machine instructions through inlining. Therefore limiting the machine to only executing entire java instructions will make it extremely slow because it cannot use any optimizations.