5 ms·

So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime? Why don't we just use an existing bytecode format and skip all the pointl

So wasm is a bytecode format like Java or C#'s IL except it basically has no runtime? Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Hell if we use one of those bytecode formats we could reuse the runtime too! I'm sure there's probably 20+ bytecode formats and I'm rolling my eyes that we need yet another for the web....

Rusky 10y ago
This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++. None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.
legulere 10y ago
Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes. This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance. LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.
coldtea 10y ago
>Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Because the major browser devs that designed WebAssembly are not smart enough to have thought this /s
rocqua 10y ago
We had Java in the browser for a while. It sucked.
fmap 10y ago
As others have already pointed out, this has been tried before. Turns out that some people are opposed to shipping LLVM with the browser, or any other large existing codebase. The reality is that WASM has to target the existing JavaScript backends in every popular browser. And now you can't use LLVM, because the backends in question typically only handle reducible control flow, etc. Conversion from LLVM to a form that your JavaScript backend supports is relatively expensive and not something you want to do on every load.

Rusky 10y ago

This has been brought up several times in this thread, but none of those bytecodes is sufficient. LLVM is not platform-agnostic, JVM/IL are sub-optimal for languages like C++. None of those platforms' security models are as good as the web's, either, nor are their runtimes able to work well in that context.

legulere 10y ago

Java (including dex) and IL bytecodes are too high level. They assume that everything is laid out in garbage collected classes. This basically means that programming languages usually have to be specially designed for them. There's ironpython, but it's not fully compatible with python for instance. LLVM IR is designed as a compiler IR and hardly useful for this usecase, as it is unstable, target-specific and has a complicated largely undocumented bitcode format (I don't know any reimplementations). It has been tried with PNaCl and the original SPIR, but both projects abandoned LLVM-IR/ were abandoned.

coldtea 10y ago

>Why don't we just use an existing bytecode format and skip all the pointless design? LLVM? Android DEX? Java Class or C# IL formats aren't enough? Because the major browser devs that designed WebAssembly are not smart enough to have thought this /s

rocqua 10y ago

We had Java in the browser for a while. It sucked.

fmap 10y ago

As others have already pointed out, this has been tried before. Turns out that some people are opposed to shipping LLVM with the browser, or any other large existing codebase. The reality is that WASM has to target the existing JavaScript backends in every popular browser. And now you can't use LLVM, because the backends in question typically only handle reducible control flow, etc. Conversion from LLVM to a form that your JavaScript backend supports is relatively expensive and not something you want to do on every load.