7 ms·

> You write in one language Not quite. Web assembly isn't a source language, it's a compiler target. So you should be able to write in C, Rust, Fortran, or Lua

> You write in one language Not quite. Web assembly isn't a source language, it's a compiler target. So you should be able to write in C, Rust, Fortran, or Lua and compile any of those to WebAssembly. Except that WebAssembly is a cross-platform assembly language/machine code which is very similar to the native machine code of many/most contemporary CPUs. This means a WebAssembly interpreter can be very straightforward, and could often translate one WebAssembly instruction to one native CPU instruction. Or rather, it can compile a stream of WebAssembly instructions almost one-to-one to native CPU instructions, which it can then execute directly.

whizzter 2y ago
A JIT should be able to translate most arithmetic and binary instructions to single-opcodes, however anything involving memory and functions calls needs safety checks that becomes multi-instruction. branches could mostly be direct _unless_ the runtime has any kind of metering (it should) to stop eternal loops (if it also wants to be crash-safe even if it's exploit safe).
- kouteiheika 2y ago
  > anything involving memory [..] needs safety checks that becomes multi-instruction Not necessarily; on AMD64 you can do memory accesses in a single instruction relatively easily by using the CPU's paging machinery for safety checks plus some clever use of address space. > branches could mostly be direct _unless_ the runtime has any kind of metering (it should) to stop eternal loops Even with metering the branches would be direct, you'd just insert the metering code at the start of each basic block (so that's two extra instructions at the start of each basic block). Or did you mean something else?
  - dist1ll 2y ago
    How do you avoid branches in 64-bit WASM?
    - kouteiheika 2y ago
      You can run the guest in another thread/process and give it its own dedicated address space, or use something like memory protection keys.
  - whizzter 2y ago
    Can't remember exactly what one but I remember reading an article about some VM that added interruption checks not at block boundaries, but rather only at _backwards_ branches and call-sites, so "safe" forward jumps (if/else/break) wouldn't cost anything extra but anything that could go on "forever" had the checks. Reserving 4gb address space oughta work on any 64bit machine with a decent OS/paging system though? I was looking into it but couldn't use it in my case however since it needs to cooperate with another VM that already hooks the PF handler (although maybe I should take another stab if there is a way to put in a hierarhcy).
  - charleslmunger 2y ago
    Metering also doesn't require a branch if you implement it with page faults. See "Implicit suspend checks" in https://android-developers.googleblog.com/2023/11/the-secret-to-androids-improved-memory-latest-android-runtime-update.html?m=1 https://android-developers.googleblog.com/2023/11/the-secret...
    - kouteiheika 2y ago
      Yep. That's a nice trick; unfortunately it's non-deterministic.
      - csjh 2y ago
        How's it nondeterministic?
beardyw 2y ago
Yes, interpretation on the fly was never its intention. The intention was to provide interpreted languages with a way to implement fast compiled functions.

whizzter 2y ago

A JIT should be able to translate most arithmetic and binary instructions to single-opcodes, however anything involving memory and functions calls needs safety checks that becomes multi-instruction. branches could mostly be direct _unless_ the runtime has any kind of metering (it should) to stop eternal loops (if it also wants to be crash-safe even if it's exploit safe).

kouteiheika 2y ago
> anything involving memory [..] needs safety checks that becomes multi-instruction Not necessarily; on AMD64 you can do memory accesses in a single instruction relatively easily by using the CPU's paging machinery for safety checks plus some clever use of address space. > branches could mostly be direct _unless_ the runtime has any kind of metering (it should) to stop eternal loops Even with metering the branches would be direct, you'd just insert the metering code at the start of each basic block (so that's two extra instructions at the start of each basic block). Or did you mean something else?
- dist1ll 2y ago
  How do you avoid branches in 64-bit WASM?
  - kouteiheika 2y ago
    You can run the guest in another thread/process and give it its own dedicated address space, or use something like memory protection keys.
- whizzter 2y ago
  Can't remember exactly what one but I remember reading an article about some VM that added interruption checks not at block boundaries, but rather only at _backwards_ branches and call-sites, so "safe" forward jumps (if/else/break) wouldn't cost anything extra but anything that could go on "forever" had the checks. Reserving 4gb address space oughta work on any 64bit machine with a decent OS/paging system though? I was looking into it but couldn't use it in my case however since it needs to cooperate with another VM that already hooks the PF handler (although maybe I should take another stab if there is a way to put in a hierarhcy).
- charleslmunger 2y ago
  Metering also doesn't require a branch if you implement it with page faults. See "Implicit suspend checks" in https://android-developers.googleblog.com/2023/11/the-secret-to-androids-improved-memory-latest-android-runtime-update.html?m=1 https://android-developers.googleblog.com/2023/11/the-secret...
  - kouteiheika 2y ago
    Yep. That's a nice trick; unfortunately it's non-deterministic.
    - csjh 2y ago
      How's it nondeterministic?

beardyw 2y ago

Yes, interpretation on the fly was never its intention. The intention was to provide interpreted languages with a way to implement fast compiled functions.