4 ms·

I guess it was an interim measure as part of the x86_64->arm transition. Now that everything targets arm, there's no need for an intermediate representation.

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"
pdpi 4y ago
bitcode predates that transition (which is very much still in play). watchOS and tvOS never had (consumer?) x86 versions, the bitcode thing was a workaround to having to build fat (multi-arch) binaries for more space-constrained devices like the Apple Watch and Apple TV.
plorkyeran 4y ago
It was an interm measure for the armv7 -> arm64 transition, where they used it to convert armv7 binaries to a wacky 32-bit version of arm64. It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.

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"

pdpi 4y ago

bitcode predates that transition (which is very much still in play). watchOS and tvOS never had (consumer?) x86 versions, the bitcode thing was a workaround to having to build fat (multi-arch) binaries for more space-constrained devices like the Apple Watch and Apple TV.

plorkyeran 4y ago

It was an interm measure for the armv7 -> arm64 transition, where they used it to convert armv7 binaries to a wacky 32-bit version of arm64. It was also used for a few misguided things over the years, like force-enabling Swift Concurrency backdeployment for apps submitted to the app store, which mostly just introduced bugs that only happened on app store/test flight installs for zero benefit.