Hacker News Reader

Comment by ryacko | Hacker News Reader

"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.

View on HN

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.

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

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?

https://en.wikipedia.org/wiki/Java_processor

x86 is translated to micro-ops in the processor. Why use x86 if you don't need a half-carry flag?

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.

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).

> 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.

“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.

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.

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.

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)

" 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://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.

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.

The PNaCL and Apple's variants are architecture independent.

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.

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.

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.

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.

Asm for Assembly, so maybe WAsm is correct?

Reply on news.ycombinator.com