3 ms·

Bitcode wouldn't help with the x86-arm transition because bitcode is still architecture specific. My guess is that maybe they don't want to maintain multiple o

by 0x0 4y ago

Bitcode wouldn't help with the x86-arm transition because bitcode is still architecture specific. My guess is that maybe they don't want to maintain multiple old toolchains to provide the on-demand bitcode->native build step on the app store servers?

pjmlp 4y ago
That is the case for standard LLVM bitcode, Apple's own version is more finetuned and probably a reason why they are moving away from it, no longer willing to keep maintaining their fork.
trollied 4y ago
>bitcode is still architecture specific Ah, I didn't know that. Thank you
- 0x0 4y ago
  Even if bitcode was fully architecture independent, you would immediately hit a wall with various framework constants having different #defined integer values. For example, https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code https://developer.apple.com/documentation/apple-silicon/addr... talks about how the NSTextAlignment enum has diverging definitions between archs. By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
  - skissane 4y ago
    > talks about how the NSTextAlignment enum has diverging definitions between archs I wonder why: was there some benefit for Apple in doing this?
    - plorkyeran 4y ago
      That specific change is possibly just a mistake. They take advantage of architecture transitions to do cleanup which they couldn't do normally because it's an ABI-breaking change. In that specific case, I'd guess they removed the enum values which were no longer actually supported and (accidentally?) renumbered the rest.
  - DaiPlusPlus 4y ago
    > the only officially supported interface to the kernel is libc aka "no fun allowed"

by 0x0 4y ago

pjmlp 4y ago

That is the case for standard LLVM bitcode, Apple's own version is more finetuned and probably a reason why they are moving away from it, no longer willing to keep maintaining their fork.

trollied 4y ago

>bitcode is still architecture specific Ah, I didn't know that. Thank you

0x0 4y ago
Even if bitcode was fully architecture independent, you would immediately hit a wall with various framework constants having different #defined integer values. For example, https://developer.apple.com/documentation/apple-silicon/addressing-architectural-differences-in-your-macos-code https://developer.apple.com/documentation/apple-silicon/addr... talks about how the NSTextAlignment enum has diverging definitions between archs. By the way something similar happens on Linux where kernel syscalls have different numbers between archs, for example. (Although on mac/ios, syscalls aren't guaranteed to be stable even across minor macos versions; the only officially supported interface to the kernel is libc)
- skissane 4y ago
  > talks about how the NSTextAlignment enum has diverging definitions between archs I wonder why: was there some benefit for Apple in doing this?
  - plorkyeran 4y ago
    That specific change is possibly just a mistake. They take advantage of architecture transitions to do cleanup which they couldn't do normally because it's an ABI-breaking change. In that specific case, I'd guess they removed the enum values which were no longer actually supported and (accidentally?) renumbered the rest.
- DaiPlusPlus 4y ago
  > the only officially supported interface to the kernel is libc aka "no fun allowed"