6 ms·

Apple has tight enough grips on their hardware and software ecosystem that they can force major architectural changes onto the userbase with a hardline take-it-

Apple has tight enough grips on their hardware and software ecosystem that they can force major architectural changes onto the userbase with a hardline take-it-or-leave-it attitude, which led them through the previous three transitions. It's much harder to succeed in massive transitions when the userbase is not being forced to and are perfectly free to stay where they are and avoid the transitional inconveniences (Itanium, IPv6, Windows on ARM, etc, etc, etc.)

saagarjha 6y ago
They also have a fair amount of software out of the gate as well as experience developing for the ISA.
- fluffything 6y ago
  And on the Apple AppStore, developers ship LLVM-IR that can be compiled to different architectures (ppc64le, x86_64, arm64, etc.), instead of pre-compiled binaries. So when Apple releases a new chip, it can just re-compile the LLVM-IR to it, to make use of newer features and compiler optimizations for that chip. Basically, the only applications that have to do anything to transition to Arm on Apple are those that are not using the AppStore... which from the platform's perspective, is kind of their own fault.
  - ajconway 6y ago
    Bitcode is architecture-dependent, you can’t just recompile it for a random target. Additionally, Mac AppStore apps are shipped without Bitcode.
    - fluffything 6y ago
      > Bitcode is architecture-dependent, you can’t just recompile it for a random target. In general, you are correct. LLVM-IR is architecture dependent. Things like the size of a pointer, the size of an `int`, parts of the calling convention, or "architecture-specific defines in C code" have already been "hardcoded"/expanded into the generated IR. In practice, you can easily re-compile x64 IR to arm64, as long as the IR does not use, e.g., "arch-specific" LLVM intrinsics (like explicitly using, e.g., NEON intrinsics). Apple does not let you ship this kind of bitcode to the AppStore, so if you want your software to use NEON on iOS, you need to call the opaque Apple math libraries, which they can just provide for a different architecture. The other things you need to worry about is, e.g., calls to system libraries (e.g. you can't call a Windows API, generate IR for it, and then try to re-compile that IR for Linux, because that API will fail to link). In practice, if you provide the symbol, everything will work, and the system APIs for MacOSX, iPadOS, and iOS are quite similar. The x86-macos IR won't be recompilable to Linux or windows, but can be made recompilable to arm-macos. Note also that this is not the first time Apple does this with the AppStore. They silently migrated all apps from 32-bit ARM to 64-bit ARM, recompiling the software for you. This hints that they have additional capabilities to changing some architecture details in the AppStore's IR, like pointer-sizes (these Apps are not running in 32-bit compatibility mode in 64-bit CPUs, but are running as native 64-bit apps). >Additionally, Mac AppStore apps are shipped without Bitcode. The Apps themselves are shipped to users as binary blobs, but developers ship bitcode to the AppStore, which Apple has been recompiling for each new arm processor in their iphones (so on an iPhone 11 you get a different binary blob than on an iphone 6, but the developer didn't ship two blobs, nor they recompiled their App).

saagarjha 6y ago

They also have a fair amount of software out of the gate as well as experience developing for the ISA.

fluffything 6y ago
And on the Apple AppStore, developers ship LLVM-IR that can be compiled to different architectures (ppc64le, x86_64, arm64, etc.), instead of pre-compiled binaries. So when Apple releases a new chip, it can just re-compile the LLVM-IR to it, to make use of newer features and compiler optimizations for that chip. Basically, the only applications that have to do anything to transition to Arm on Apple are those that are not using the AppStore... which from the platform's perspective, is kind of their own fault.
- ajconway 6y ago
  Bitcode is architecture-dependent, you can’t just recompile it for a random target. Additionally, Mac AppStore apps are shipped without Bitcode.
  - fluffything 6y ago
    > Bitcode is architecture-dependent, you can’t just recompile it for a random target. In general, you are correct. LLVM-IR is architecture dependent. Things like the size of a pointer, the size of an `int`, parts of the calling convention, or "architecture-specific defines in C code" have already been "hardcoded"/expanded into the generated IR. In practice, you can easily re-compile x64 IR to arm64, as long as the IR does not use, e.g., "arch-specific" LLVM intrinsics (like explicitly using, e.g., NEON intrinsics). Apple does not let you ship this kind of bitcode to the AppStore, so if you want your software to use NEON on iOS, you need to call the opaque Apple math libraries, which they can just provide for a different architecture. The other things you need to worry about is, e.g., calls to system libraries (e.g. you can't call a Windows API, generate IR for it, and then try to re-compile that IR for Linux, because that API will fail to link). In practice, if you provide the symbol, everything will work, and the system APIs for MacOSX, iPadOS, and iOS are quite similar. The x86-macos IR won't be recompilable to Linux or windows, but can be made recompilable to arm-macos. Note also that this is not the first time Apple does this with the AppStore. They silently migrated all apps from 32-bit ARM to 64-bit ARM, recompiling the software for you. This hints that they have additional capabilities to changing some architecture details in the AppStore's IR, like pointer-sizes (these Apps are not running in 32-bit compatibility mode in 64-bit CPUs, but are running as native 64-bit apps). >Additionally, Mac AppStore apps are shipped without Bitcode. The Apps themselves are shipped to users as binary blobs, but developers ship bitcode to the AppStore, which Apple has been recompiling for each new arm processor in their iphones (so on an iPhone 11 you get a different binary blob than on an iphone 6, but the developer didn't ship two blobs, nor they recompiled their App).