Hacker News Reader

Comment by klodolph | Hacker News Reader

I’m curious what you’re talking about—WASM has different instructions for each of its different types. There are separate instructions for i32, i64, f32, and f64 in the base spec.

This seems like a pretty clean map to me—most of the architectures these days have native support for 32-bit and 64-bit types these days. You only get 16-bit and 8-bit support with SIMD or load/store, much like how WASM does it.

View on HN

He might be talking about having to implement a register allocator/file in order to interpret stack machines faster. Something you get from the compilers on register architectures like RISC-V, ARM and x86.

wasmtime uses cranelift, which has a complex register allocator. wasm3 uses a simple register file.

> In M3/Wasm, the stack machine model is translated into a more direct and efficient "register file" approach.

https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md

Because registers on x86 and RISC-V are different, you still need to have a register file to map those, no?

Only for binary translation or just-in-time compilation (basically producing native code). If you're interpreting RISC-V you can just pretend the registers are an array of register-sized integers. Which is what they are.

>registers are an array of register-sized integers

A "register file" is the name of such an array.

Take for example i32.add you have to

1. Check the type at the top of the stack to make sure it's i32 and trap otherwise

2. Pop the top of the stack

3. Check the top of the stack and make sure it's i32 and trap otherwise

4. Pop the top of the stack.

5. Add the two values together

6. Push the result to the top of the stack along with its type.

Compare this to ADD from RISC-V where you can just add the contents of 2 source registers and store it in a destination register. There is not a bunch of type book keeping or alignment that you have to worry about.

Most of this can be done statically. You do the bookkeeping once. There are various approaches—you can try to allocate registers, or you can emit code that loads/stores on the stack, or you can just run an interpreter and remove the safety checks from it.

The stack isn’t dynamically typed, so it doesn’t make sense to trap.

Looking into it further the type checking is supposed to be done in a dedicated validation step and other than validation using instructions with the wrong type of data seems to work.

WASM is a stack-machine, so the input code needs to be validated to make sure that the same types gets pop'ed as has previously been push'ed. But that can be done ahead of execution.

You'd need to validate function types during runtime though, which is something that a CPU emulator does not need to.

WASM is kind of a stack machine, yes, but there are a lot of constraints on the stack machine that are designed to make it easy to translate to registers.

If you squint and look sideways, you can think of it as a flattened tree, rather than a stack machine.

In contrast, RISC-V would be considered a register-based VM here.

I'm not familiar with the details, and don't have the references to hand, but WASM has been designed in a way that reflects the design choices of Chrome's Javascript engine rather than optimizing standalone compilation.

Part of optimizing for the design choices of browser engines is to make it easy to emit machine code. The browsers have multiple compilers in them, and one of the compilers has the task of emitting simple machine code quickly, so the code can run immediately (reducing start-up time). In V8, this initial compiler is called Ignition.

>WASM has been designed in a way that reflects the design choices of Chrome's Javascript engine

Wasn't it based on previous work by the Mozilla team?

Reply on news.ycombinator.com