Somewhat related to the above, what is the differe...

# kotlin-native

[mbonnin]

Somewhat related to the above, what is the difference between iOSArm64 and iOSSimulatorArm64 ? Could they somehow be merged as the instruction sets are the same? Or are the APIs different somehow?

[Sebastien Leclerc Lavallee]

From my understanding, the iOSArm64 is a real device running Arm64 (all devices since… iPhone 5S I think) and the iOSSimulatorArm64 is for the simulator running on Arm64 computers, the new Macs with M1/M1Pro/M1Max chips.

[mbonnin]

I understand the same that but how is the instruction set or API different between a phone M1 and a Mac M1?

[mbonnin]

Or does the M1 include newer instructions maybe? In which case, it should more be like iOSArm64 and iOSM1 ?

[Sebastien Leclerc Lavallee]

As far as I know, there isn’t any phone with M1 chip. The A12 chip line is for iPhone and iPad and the M1 line is for computers. They are acquainted but doesn’t seems exactly the same. So this might be the reason. But I’m no chip expert 🙂

[mbonnin]

You're right, the iPhone doesn't have M1, only A12

[mbonnin]

According to Wikipedia,
• A12 is ARMv8.3-A
• M1 is ARMv8.4-A

[mbonnin]

So maybe iOSSimulatorArm64 can use some of the "8.4" features ?

[mbonnin]

But all of that is Arm64 still according to Wikipedia

[Sebastien Leclerc Lavallee]

Indeed, they are all Arm64 chipsets. Now that’s the limit of my knowledge 😆

[kpgalligan]

Apple should ship macbook pro with an A12 and just use it for the simulator. Make everybody's life simpler and more realistic /s

[kpgalligan]

I'm kidding sort of, but it would be nice

[Sebastien Leclerc Lavallee]

Indeed, that would be pretty nice! A step forward to have the simulator less simulator!

[mbonnin]

I'm still somewhat skeptical that iOSSimulatorArm64 uses any of the M1-specific instructions

[mbonnin]

I'd happily have it downgrade to ARM-v8.3 if that can save minutes of linking time

[kpgalligan]

I think you're probably right, but that whole thing is complicated. We just ran into a situation where somebody wanted to build Catalyst apps, but that's 100% not possible with Kotlin/Native at this point.

[ephemient]

afaik the difference is that simulator binaries need to be marked as such (eg os=macos vs ios)

[mbonnin]

Which raises the question of why it needs to be marked... (feeling like a 4 y.o. discovering the world right now 😅 )

[ephemient]

in the case of macos/iOS ARM, they probably don't. if you manually edit the binary it tends to work: https://bogo.wtf/arm64-to-sim-dylibs.html

[ephemient]

but in general binary formats embedded the target architecture and os, as there can be differences

[ephemient]

e.g. Windows, Linux, and OS X each use a different calling convention on the same x86-32 architecture

[mbonnin]

Interesting, thanks for the link!

[hfhbd]

The M1 based on A13, so there is no big difference from CPU side. In practice, the simulator does not support all modules/sensors, eg AR, gyroscope.

[Sam]

I believe they link against different libraries even though the architectures are the same. You don’t strictly need the arm64 simulator slice. On M1 based macs in Xcode, apps can be run directly using the My Mac (Designed for iPad) mode. If you’re using SwiftUI though, you still need to build a simulator target or previews won’t work.

[ephemient]

the simulator has the ≈same libraries that the devices do

[ephemient]

in theory Apple doesn't need to use such a similar ABI on iOS vs iOSSimulator. but on the other hand there's not really any reason for them not to be the ≈same

[mbonnin]

We "just" need jetbrains to build iOSSimulatorArm64 from iOSArm64 and then patch it with https://github.com/bogo/arm64-to-sim 🙂

[mbonnin]

And BOOM, 10min CI time reclaimed!

[kpgalligan]

Interesting!

[mbonnin]

That'd be super dirty but looks like that could work...

[kpgalligan]

That feels like one of those things that works until it doesn't, and then it's a nightmare, but hey, 10 minutes!

[mbonnin]

Exactly, that'll break any time Apple touches anything in the binary format 😅

[mbonnin]

That could maybe be made as a third party "use at your own risk" Gradle plugin

[hfhbd]

It would more love to see faster builds than some "hacks", eg parallel c compiling and linking (https://youtrack.jetbrains.com/issue/KT-49385)

[louiscad]

@mbonnin Are you actually considering making such a Gradle plugin?

[mbonnin]

That'd be like project #512 😅

[mbonnin]

So don't hold your breath ! 🙃