4 ms·

For the reverse, I wrote a WASM-to-JVM compiler: https://github.com/cretz/asmble https://github.com/cretz/asmble. I think WASM has the ability for us to finall

For the reverse, I wrote a WASM-to-JVM compiler: https://github.com/cretz/asmble https://github.com/cretz/asmble. I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI. But at this early stage, there's no common stdlib for all languages to share.

benjaminjackman 9y ago
That's really interesting! How does calling WASM code on the JVM work? And also in addition to a stdlib, maybe a great package management system. Is there a popular crate / maven / npm etc equivalent out there for wasm yet?
- wging 9y ago
  There seems to be a good deal of info in the README: https://github.com/cretz/asmble#compilation-details https://github.com/cretz/asmble#compilation-details I haven't dug deeply but it seems from the documentation that the project is trying to do things the 'right' way (mapping instructions to JVM bytecodes at a low level)... as opposed to, say, trying somehow to compile to Java code.
hrjet 9y ago
There is also a WASM to Java source transpiler: https://github.com/wrmsr/wava https://github.com/wrmsr/wava
pjmlp 9y ago
> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI That is how many maninframes work, and the original idea behind the CLR.
- bdamm 9y ago
  Isn't the CLR just the same as the JVM?
  - pjmlp 9y ago
    No. CLR was designed to be able to support multiple kinds of languages, including C and C++. At the release event there were about 40 languages being supported by multiple vendors. The SDK being offered across multiple developer magazines had samples for several languages. CLR was born from Ext-VOS project, formelly known as COM Runtime, the idea being that Windows would eventually be fully .NET based. The idea never came to be, because .NET belongs to DevTools and Windows team was never happy with it. The biggest example being the sabotage during Longhorn development and how the Phoenix, Singularity and Midori projects were received by them. Also CLR always had the option of AOT compilation. Initially via NGEN, Bartok in Singularity later adopted in Windows 8 for store apps, Project N from Midori later .NET Native for UWP apps.
earenndil 9y ago
> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI Uhhhhh. This sounds like a kind of silly thing to say, when you just described the jvm. Except for the part where there is a common stdlib.
- sitkack 9y ago
  If only the JVM had included unsigned math.
  - xxs 9y ago
    there is... 'char'; char is an unsigned 16bit primitive (of course, adding 2 chars results into an int and you need a cast but that's another story)
  - pjmlp 9y ago
    Legend goes Gosling did not found anyone at his department that could answer all his questions about unsigned arithmetic, hence why he left it out from Java's initial design. However since Java 8, the java.lang numeric classes do support unsigned arithmetic. Yes it is a bummer that byte is signed, requiring extra math to simulate unsigned.
    - kodablah 9y ago
      Yup, I use those unsigned methods, e.g. https://github.com/cretz/asmble/blob/3cb439e887245f23bf876e8be7c68aa2ef1c920f/compiler/src/main/kotlin/asmble/compile/jvm/FuncBuilder.kt#L247 https://github.com/cretz/asmble/blob/3cb439e887245f23bf876e8.... Luckily WASM only has 32/64 bit integer arithmetic.
- exabrial 9y ago
  I would have had a great answer: Normally I count upwards from 0.
- kodablah 9y ago
  > Except for the part where there is a common stdlib. Yeah, and it's huge and interconnected (just see how much they had to do to get a java.base module and how large that still is). And the JVM has lots of specifics around threading, GC, OOP, classes, security model, etc. And many of those specifics don't translate to the needed safe-by-default, minimal-by-default bytecode for the web and other targets. I could really go on for a long time about why applets failed and why JVM bytecode and the JVM runtime are terrible for the web (and any generic bytecode that doesn't target the web can't really be that generic). What is silly is ignoring all of this. Think about why there are already C++-to-WASM compilers after such a short time and no reasonably-usable and maintained C++-to-JVM compilers.

benjaminjackman 9y ago

That's really interesting! How does calling WASM code on the JVM work? And also in addition to a stdlib, maybe a great package management system. Is there a popular crate / maven / npm etc equivalent out there for wasm yet?

wging 9y ago
There seems to be a good deal of info in the README: https://github.com/cretz/asmble#compilation-details https://github.com/cretz/asmble#compilation-details I haven't dug deeply but it seems from the documentation that the project is trying to do things the 'right' way (mapping instructions to JVM bytecodes at a low level)... as opposed to, say, trying somehow to compile to Java code.

hrjet 9y ago

There is also a WASM to Java source transpiler: https://github.com/wrmsr/wava https://github.com/wrmsr/wava

pjmlp 9y ago

> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI That is how many maninframes work, and the original idea behind the CLR.

bdamm 9y ago
Isn't the CLR just the same as the JVM?
- pjmlp 9y ago
  No. CLR was designed to be able to support multiple kinds of languages, including C and C++. At the release event there were about 40 languages being supported by multiple vendors. The SDK being offered across multiple developer magazines had samples for several languages. CLR was born from Ext-VOS project, formelly known as COM Runtime, the idea being that Windows would eventually be fully .NET based. The idea never came to be, because .NET belongs to DevTools and Windows team was never happy with it. The biggest example being the sabotage during Longhorn development and how the Phoenix, Singularity and Midori projects were received by them. Also CLR always had the option of AOT compilation. Initially via NGEN, Bartok in Singularity later adopted in Windows 8 for store apps, Project N from Midori later .NET Native for UWP apps.

earenndil 9y ago

> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI Uhhhhh. This sounds like a kind of silly thing to say, when you just described the jvm. Except for the part where there is a common stdlib.

sitkack 9y ago
If only the JVM had included unsigned math.
- xxs 9y ago
  there is... 'char'; char is an unsigned 16bit primitive (of course, adding 2 chars results into an int and you need a cast but that's another story)
- pjmlp 9y ago
  Legend goes Gosling did not found anyone at his department that could answer all his questions about unsigned arithmetic, hence why he left it out from Java's initial design. However since Java 8, the java.lang numeric classes do support unsigned arithmetic. Yes it is a bummer that byte is signed, requiring extra math to simulate unsigned.
  - kodablah 9y ago
    Yup, I use those unsigned methods, e.g. https://github.com/cretz/asmble/blob/3cb439e887245f23bf876e8be7c68aa2ef1c920f/compiler/src/main/kotlin/asmble/compile/jvm/FuncBuilder.kt#L247 https://github.com/cretz/asmble/blob/3cb439e887245f23bf876e8.... Luckily WASM only has 32/64 bit integer arithmetic.
exabrial 9y ago
I would have had a great answer: Normally I count upwards from 0.
kodablah 9y ago
> Except for the part where there is a common stdlib. Yeah, and it's huge and interconnected (just see how much they had to do to get a java.base module and how large that still is). And the JVM has lots of specifics around threading, GC, OOP, classes, security model, etc. And many of those specifics don't translate to the needed safe-by-default, minimal-by-default bytecode for the web and other targets. I could really go on for a long time about why applets failed and why JVM bytecode and the JVM runtime are terrible for the web (and any generic bytecode that doesn't target the web can't really be that generic). What is silly is ignoring all of this. Think about why there are already C++-to-WASM compilers after such a short time and no reasonably-usable and maintained C++-to-JVM compilers.