4 ms·

You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned typ

You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are aware of.

layer8 4y ago
Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.
- sitkack 4y ago
  > JVM and WASM [sic] is that the JVM doesn’t have untyped linear memory like WASM does. As you say, it can be trivially emulated, no reason that linear memory couldn't be implemented on the JVM using an array of primitive (char,int,long). The Wasm VM is more generic and has a better capabilities security model than the JVM. Had the JVM been more like Wasm (signed and unsigned primitives, capabilities model), it would have been a natural compilation target for sandboxing native code. As Wasm gets more features it becomes more like the JVM (GC, reference types, component model). Eventually Wasm will subsume all the features that differentiates them.

layer8 4y ago

Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform. The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects. Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.

sitkack 4y ago
> JVM and WASM [sic] is that the JVM doesn’t have untyped linear memory like WASM does. As you say, it can be trivially emulated, no reason that linear memory couldn't be implemented on the JVM using an array of primitive (char,int,long). The Wasm VM is more generic and has a better capabilities security model than the JVM. Had the JVM been more like Wasm (signed and unsigned primitives, capabilities model), it would have been a natural compilation target for sandboxing native code. As Wasm gets more features it becomes more like the JVM (GC, reference types, component model). Eventually Wasm will subsume all the features that differentiates them.