I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?
WASM is a poor target for hardware, for reasons that don't matter at all to JITs. It has an unbounded stack, its branch instructions use tags rather than relative offsets, its calls use a function table which would be doubly-indirect in hardware, and such.
> "I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?"
You're asking for unified, standardized, cross-vendor hardware + instruction sets.
Why not do this other way around though? "Compile" JS to WASM, then to x86/x64. Finally just execute on the bare metal.
Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?
> "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?"
I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical question.
Are CPUs these days not performing well enough for most applications? If so, is it necessarily due to the complex instruction sets powering those platforms?
I'm sure you aren't doing this consciously, but you're answering completely different ones that are easier to dismiss than the original one that more difficult to answer. It comes across as using a straw man.
int_19h is not asking a very broad, theoretical question so much as that it is a difficult question to answer, requiring specific technical know-how about CPUs and compiler design.
Saying that one can compile WASM into Japanese or French is not an answer to "is x86/x64 (or ARM) an ideal target architecture for WASM", so irrelevant.
Whether or not "CPUs these days [are] not performing well enough for most applications" is not relevant for answering GPs question. It's a justification for you not to have to answer his question. But ultimately, whether or not there would be a point to targeting WASM in the hardware is unrelated to whether it is possible, and what the limitations are. Also: did most websites need the performance of V8 when it came out? No, because no website used JavaScript intensely due to its slow performance.
Theoretically it would let you ditch a lot of outdated instructions for something a lot simpler, enabling smaller, more efficient (power-wise) hardware.
ARM abandoned their JVM bytecode execution tech a decade ago because JIT compilers became faster than it. So the same would probably be true with WASM.
Worthwhileness would depend on your motivation for doing it.
I guess a very tiny microcontroller could be a use case, where it's a good tradeoff to save some memory (=cost) by eliding the JIT even if execution is slow. Even then you could just replace this with offine binary translation.
