51–60 of 79 posts
The motivation for WebAssembly rather than plain ARM or x86 assembly = portability, security. It would be interesting to see how this is designed for security in mind.
This is designed for microcontrollers. If you're running untrusted code on microcontrollers, you've got bigger problems.
Earlier quoted context omitted.
Any JIT needs an interpreter to run code sections that are not compiled (yet), and large sections (I don't have any statistics, but I would guess a very sizable majority) of the code is 'cold' and will never get compiled at all. Compiling bytecode to machine code is a relatively expensive operation in itself so it only makes sense to do it for 'hot' sections (loops, functions that get called many times, etc).
There JIT implementations without interpreter phase, .NET being one of them.
Earlier quoted context omitted.
There JIT implementations without interpreter phase, .NET being one of them.
It appears that Mono has added the interpreter back: https://www.mono-project.com/news/2017/11/13/mono-interprete... . I think the CLR has one too, but I haven't looked into it much: https://github.com/dotnet/runtime/blob/master/src/coreclr/sr...
Earlier quoted context omitted.
It appears that Mono has added the interpreter back: https://www.mono-project.com/news/2017/11/13/mono-interprete... . I think the CLR has one too, but I haven't looked into it much: https://github.com/dotnet/runtime/blob/master/src/coreclr/sr...
From Microsoft side, regular CLR never had one, only the .NET MF variant.
These are impressive performance numbers. > Because operations end with a call to the next function, the C compiler will tail-call optimize most operations. It appears that this relies on tail-call optimization to avoid overflowing the stack. Unfortunately this means you probably can't run it in debug mode.
This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…
Sure this is neat stuff, but I don't think any of it is novel. Bochs is a good source for some bytecode vm performance wizardry [1], even if the bytecode in question is the x86 ISA. Regardless, kudos to the authors and nice to see a fast wasm interpreter done well. 1: http://www.emulators.com/docs/nx25_nostradamus.htm
The neater article seems to be about M3 interpreter https://github.com/soundandform/m3#m3-massey-meta-machine Tbh, I couldn't get the eureka moment though. Might try to read in the AM ;)
Yeah, this is a good way to design a fast interpreter! It's traditionally called a "threaded interpreter", or (somewhat confusingly) "threaded code": https://en.wikipedia.org/wiki/Threaded_code http://www.complang.tuwien.ac.at/forth/threaded-code.html You can see an example of this particular implementation style (where each operation is a tail call to a C function, passing the registers as arguments) at the second l…
Earlier quoted context omitted.
> "WASM translated to register-based bytecode. That's awesome!" If the hardware executing this code is "stack-based" (or, does not offer enough general purpose registers to accomodate the funtion call) - this will need to be converted back to a stack-based function call (either at runtime, or beforehand). Wouldn't this intermediate WASM-to-register-based-bytecode translation be redundant then?
I don't know of any current physical stack machine CPUs.