:loudspeaker: Update Regarding Kotlin/Native Targe...

# kotlin-native

[Kathrin Petrova]

📢 Update Regarding Kotlin/Native Targets

Kotlin/Native supports many targets – 27 as of 1.8.0, to be exact! While most of the heavy lifting is already being done by LLVM, we still have a lot of work to do.
At the beginning of the Kotlin/Native project, we explored the possibilities and limits of the technology by adding different, sometimes exotic, targets. With the Stable release approaching, we, unfortunately, have to admit that we can’t support all targets equally well. Please, read this update regarding Kotlin/Native targets to find out our plans for supporting individual targets.

[Moussa]

I personally agree with above very much 😄
Keep up the awesome work 💪💪💪

[hfhbd]

Do you have any plans to add some target (compiler) plugin to easily add a custom/removed target?

[napperley]

Everything looks good except for the deprecation of the linuxArm32Hfp target, which I object to. A comment has been left in the blog post. Anyone that objects to the deprecation of the linuxArm32Hfp target should leave a comment in the blog post ☑️, otherwise the Kotlin team will deprecate the target unopposed.

Many Kotliners will be very surprised to see that the linuxArm32Hfp target covers multiple ARM CPU architectures, why was this done? Does the linuxArm64 target cover multiple ARM CPU architectures like the linuxArm32Hfp target?

With the linuxArm32Hfp target many Kotliners thought this only covered the ARM v7 CPU architecture. Covering multiple CPU architectures in a single target (not considered porting best practise) is a very bad design decision. Go and C for example don't have a target that covers multiple CPU architectures.

Basic research into CPU architectures used on Linux reveals that ARM v7, and ARM v8 is very widely used as much as AMD64. The Linux ARM v7 ecosystem is large with most open source software available for the CPU architecture. Many industrial devices are running some form of Embedded Linux on ARM v7, instead of ARMv8 for cost reasons (can easily acquire an industrial device for software development/testing purposes). To this very day there are ARM v7 SoC's (System On A Chip) produced by major manufacturers (eg i.MX 7 series by NXP).

[napperley]

If the Kotlin team are determined to go ahead with deprecating the linuxArm32Hfp target, then it should be replaced with a new target called linuxArmv7 that covers Linux on an ARM v7 device (an excellent solution that addresses the deprecation issue). By the way ARM v7 is a 32 bit ARM architecture that includes a hardware FPU (Floating Point Unit).

Numerous advantages can be seen with the linuxArmv7 target:
1. Only covers a single CPU architecture making it significantly easier to support
2. Fewer resources required to maintain the target
3. Easy to acquire Linux ARM v7 devices
4. Most Linux open source software is available for ARM v7, and is well maintained
5. Many *consumer*/*industrial* Embedded Linux devices using ARM v7 (very common)
6. Some of the major CI systems (eg TeamCity) support the Linux ARM64 target (backwards compatible with Linux ARM v7 software)

[elizarov]

ARM v7 is, indeed, a popular architecture for embedded devices. Given the memory restrictions however, it is traditionally developed on using systems languages that are designed with a different mindset. While it certainly is possible to create embedded software with Kotlin which uses GC and targets a machine with limited resources, it isn’t something that we believe would have a large market and therefore it is not viable for us to try and target it, especially taking into account that the ARM v8 is and will be supported by Kotlin/Native. This is a market we see great potential in and we’re committed to supporting it

[natario1]

This is great news - when can we expect the first atomicfu/coroutines release for androidNative? Will ktor follow this scheme too?

[Marcin Wisniowski]

linuxArm32Hfp going away? 😢 I guess no more updates for my Kotlin/Native table football modded automatic scoring system: https://marcin.wisniowski.space/project/footballtable

[Moussa]

@Marcin Wisniowski very sorry to hear that. Will it be much work to update the hardware to use 64 one instead

[Marcin Wisniowski]

It’s certainly a possible path forward for me.

[napperley]

All changes required to move from linuxArm32Hfp to linuxArm64 are minor (very little work required), which is the good news. If older hardware (ARM v7 based) needs to be used then the move to linuxArm64 won't be feasible (will be bad news in some cases).