Curious if anyone ever thought about the possibili...

# kotlin-native

[Edoardo Luppi]

Curious if anyone ever thought about the possibility of a z/Architecture target for Native.
AFAIK LLVM supports that target too

[hfhbd]

Yes, I thought about it, but there are a few obstacles:

easy one: calling the llvm compiler with custom (target) options: https://youtrack.jetbrains.com/issue/KT-37368/Native-compiler-fails-to-compile-big-projects#focus=Comments-27-4650164.0-0

Beside llvm support, you also need runtime support, Gradle support (easy), and you need to fork each library you want to use and compile it with your z/OS Kotlin compiler and distribute it (easy but annoying).

Runtime would be the hardest part, you need to port the cpp runtime. Maybe, you may also need to support a modern posix standard (z/OS uses POSIX 95). From my business perspective, the most important feature to use Kotlin on z/OS is calling Cobol programs including passing values. This requires linking support too.

But the biggest problem during porting the runtime is EBCDIC. You need to convert string literals (which are in utf-8) to ebcdic. There is blog post from IBM about the Swift 4 port discussing the same problem: https://forums.swift.org/t/z-os-swift-and-encodings/5897 (IBM dropped Swift 5 support...)

See also https://youtrack.jetbrains.com/issue/KT-57111/Provide-Kotlin-Targets-Plugin-System
https://youtrack.jetbrains.com/issue/KT-43974/More-flexible-cross-compilation-in-Kotlin-Native

But I am really open to try all these things 🙂

[Edoardo Luppi]

Seems like a lot of work. I didn't think about all these challenges, yeah...
Well, maybe once KMP has matured it will become easier to add custom targets too.
I think it would attract many people to the ecosystem

[Edoardo Luppi]

In the socket library I'm implementing I'm converting strings from ASCII to CP037 and other EBCDIC code pages using conversion tables. Very tedious, but it works

[hfhbd]

I guess, I missed some parts too :D

[hfhbd]

You don't use iconv?

[Edoardo Luppi]

The library is multiplatform (Node and JVM, maybe native soon) and the goal is to not depend on external binaries or other dependencies

[Edoardo Luppi]

On the JVM I'm using Ktor with NIO but that's it.

[hfhbd]

Do you need to read files? I do including comp and signed/zoned values. I guess this would require more than just a conversation table.

[hfhbd]

But at the moment, we only use JVM and JNI.

[Edoardo Luppi]

No I don't need to do that, in that case I would have probably done it like you. The protocol only exchanges small messages (synchronously and asynchronously).
You can compare it a slightly simplified version of Telegram's MTProto

[Edoardo Luppi]

I've borrowed many ideas from MTProto