Hi Kotlin/Wasm team, I noticed that Kotlin/Wasm ha...
# webassembly
r
Hi Kotlin/Wasm team, I noticed that Kotlin/Wasm has its own Wasm IR for generating Wasm binary or WAT. It's a really great work! https://github.com/JetBrains/kotlin/blob/8fcf91d8efda8b84e468eb14633e4a5a1b9ac659/[…]r/src/org/jetbrains/kotlin/wasm/ir/convertors/WasmIrToBinary.kt I'm curious why Kotlin/Wasm decided to create its own Wasm IR instead of using Binaryen IR (via C-FFI), which supports various Wasm features including WasmGC. context: I'm having difficulty testing the JNA mapper for Binaryen in Kotlin https://github.com/irmen/binaryen-interfaces/blob/master/kbinaryen/src/main/kotlin/razorvine/kbinaryen/Binaryen.kt or creating my own in Java https://github.com/tanishiking/binaryen4s-kitchen-sink/blob/main/src/main/java/BinaryenLibrary.java; it easily results in a SIGSEGV for more complex examples than a simple "hello-world." Now, I'm curious if developing our own WebAssembly Intermediate Representation (Wasm IR) like Kotlin/Wasm did would be a viable option for my toy Wasm compiler.
TBH, after examining Binaryen C API, I'm getting to think that maybe building our own Wasm IR and it's converter wouldn't be that much hard than I thought 😃 Anyway, great job!
Ah, also I realized that while WasmIR is introduced in the late 2020 https://github.com/JetBrains/kotlin/commit/3be38d17965309c27e32af0fb51dfee133e7d057 WasmGC instructions support in Binaryen are not yet completed in 2020. e.g. https://github.com/WebAssembly/binaryen/pull/4998 it's in 2022
s
Hi! I do not know about any issues with using binaryen C API IR to generate Wasm, but I haven’t tried to setup binaryen JNA myself. My intuition is that binarien API surface area is relatively high compared to the volume of binary generation logic (with
-O0
), so it may not be a very big win. Eventually, when things settles down, we could get rid of Wasm IR in Kotlin and generate Wasm binary directly from Kotlin backend IR. This would allow for faster dev/debug builds. On the other hand, integration with binaryen could make production/optimized build time faster. I’m happy with our Wasm IR for the time being.
But main reasons for Wasm IR were: historical, avoiding a mandatory native dependency, and potentially faster debug builds in the future.
r
Thank you for your response! Yeah, as long as Wasm syntax structure is not that complicated, there seems no big traction to use binaryen for code generation 👍 Thanks again for your explanation!
s
Also, as an alternative to C FFI, Binaryen API are also available in JavaScript. Can’t tell if this would be easier or harder to integrate into Kotlin/Java.