3 ms·

> a compiler that emits trustable code, regardless of how untrusted the source is Hasn't this been one of the goals of the design of WebAssembly since day one,

> a compiler that emits trustable code, regardless of how untrusted the source is Hasn't this been one of the goals of the design of WebAssembly since day one, and something that has been getting people excited about it too? Using something for one of its intended purposes isn't really a "hack", no?

oefrha 5y ago
The hack is translating wasm back to C, then compiling again. It wouldn’t be a hack if they’re running wasm, but they’re not.
- masklinn 5y ago
  AFAIK the ability to compile wasm to native code was pretty much always part of the goal, running wasm in a VM was never the end-game. Compiling via C might be considered a hack (especially in the sense that it introduces a potential weak link in the chain), but it makes a lot of sense since they want to integrate the result into the Firefox build artefacts, and compiling via C is not exactly novel either.
IshKebab 5y ago
Sort of. The main goal for WebAssembly is to be a fast platform-agnostic compilation target that you can use in websites. The "in websites" bit means that it has to be completely safe (i.e. no accessing outside memory etc.) but it's not the main goal. This is a bit of a hack because Mozilla don't care about the platform-agnostic bit, so they're taking LLVM IR, compiling it to WebAssembly, then back to LLVM IR just so that they can ensure that the code is safe. WebAssembly comes with extra constraints that you probably don't care about if you're compiling to native (e.g. there's no 'goto') so you would get more efficient code (and probably faster compilation) if you just had some way of compiling LLVM IR directly to "safe binary". That would probably be a mountain of work though so its understandable why they went with this. Would be nice if they said how much the performance was impacted.

3 ms·

> a compiler that emits trustable code, regardless of how untrusted the source is Hasn't this been one of the goals of the design of WebAssembly since day one,

by vanderZwan 5y ago

oefrha 5y ago
The hack is translating wasm back to C, then compiling again. It wouldn’t be a hack if they’re running wasm, but they’re not.
- masklinn 5y ago
  AFAIK the ability to compile wasm to native code was pretty much always part of the goal, running wasm in a VM was never the end-game. Compiling via C might be considered a hack (especially in the sense that it introduces a potential weak link in the chain), but it makes a lot of sense since they want to integrate the result into the Firefox build artefacts, and compiling via C is not exactly novel either.
IshKebab 5y ago
Sort of. The main goal for WebAssembly is to be a fast platform-agnostic compilation target that you can use in websites. The "in websites" bit means that it has to be completely safe (i.e. no accessing outside memory etc.) but it's not the main goal. This is a bit of a hack because Mozilla don't care about the platform-agnostic bit, so they're taking LLVM IR, compiling it to WebAssembly, then back to LLVM IR just so that they can ensure that the code is safe. WebAssembly comes with extra constraints that you probably don't care about if you're compiling to native (e.g. there's no 'goto') so you would get more efficient code (and probably faster compilation) if you just had some way of compiling LLVM IR directly to "safe binary". That would probably be a mountain of work though so its understandable why they went with this. Would be nice if they said how much the performance was impacted.