4 ms·

The problem I have with that is that this company is known for its disrespect of standards. Some techies are already confused about the nature of the ISA and a

The problem I have with that is that this company is known for its disrespect of standards. Some techies are already confused about the nature of the ISA and architecture. Pretty soon, people will forget that iOS and macOS are running on ARM, like many many other devices. For once they have the ability to adopt a standard and even push it forward with the incredible engineering of their hardware teams, but they seems to choose, again, the other route.

saagarjha 4y ago
Apple designed much of aarch64.
inkyoto 4y ago
You are barking up the wrong tree. The ABI compatibility is never expected nor is taken for granted, for it is an internal implementation aspect of an operating system. An ISA does not equate to an ABI either. Blaming Apple for devising or augmenting an aarch64 ABI is akin to blaming IBM for using the XCOFF and the AIX ABI on their POWER platforms rather than using the SysV ELF ABI on the same POWER platform that Linux is a signatory to. Incompatible ABI's used to be a common place across different UNIX flavours from different vendor running on the same ISA. DEC Ultrix running on MIPS used an ABI distinct from that of SGI Irix running on the same MIPS ISA. For many years the ABI was not even recognised as a thing and was rather very loosely based on the original PDP-11 ABI (e.g. the result is either in the zeroeth register of the CPU however it was actully named, or on the stack if the result was too big to fit in, input parameters either in the first 4-5 registers or on the stack etc). It took years of bickering amongst UNIX vendors until the SysV ELF ABI was finaliased and adopted across all modern UNIX implementations (sans Mach-O on Darwin and XCOFF on AIX). Linux went all in with the ELF ABI as it was well positioned to get away from a zoo of legacy ABI's it historically had to support on different hardware plaftorms (a.out, COFF, ECOFF and whatever else there was out there) even at the cost of the performance loss on the 32-bit x86. Whereas all BSD's (Free, Net and Open) just baulked at it and stuck with the historical BSD ABI for several more years to renege later on.
theresistor 4y ago
In this case, many of the divergences exist because the standard AArch64 ABI (AAPCS) wasn't finalized at the time that iOS had to lock its ABI. Several items are actually the standard version from pre-finalization versions of AAPCS, and couldn't be changed to match the standard because iOS binary compatibility was already locked in.
steve1977 4y ago
Disrespect of standards? As one of the founding members of Advanced RISC Machines Ltd back in 1990, Apple is rather behind those standards.

saagarjha 4y ago

Apple designed much of aarch64.

inkyoto 4y ago

You are barking up the wrong tree. The ABI compatibility is never expected nor is taken for granted, for it is an internal implementation aspect of an operating system. An ISA does not equate to an ABI either. Blaming Apple for devising or augmenting an aarch64 ABI is akin to blaming IBM for using the XCOFF and the AIX ABI on their POWER platforms rather than using the SysV ELF ABI on the same POWER platform that Linux is a signatory to. Incompatible ABI's used to be a common place across different UNIX flavours from different vendor running on the same ISA. DEC Ultrix running on MIPS used an ABI distinct from that of SGI Irix running on the same MIPS ISA. For many years the ABI was not even recognised as a thing and was rather very loosely based on the original PDP-11 ABI (e.g. the result is either in the zeroeth register of the CPU however it was actully named, or on the stack if the result was too big to fit in, input parameters either in the first 4-5 registers or on the stack etc). It took years of bickering amongst UNIX vendors until the SysV ELF ABI was finaliased and adopted across all modern UNIX implementations (sans Mach-O on Darwin and XCOFF on AIX). Linux went all in with the ELF ABI as it was well positioned to get away from a zoo of legacy ABI's it historically had to support on different hardware plaftorms (a.out, COFF, ECOFF and whatever else there was out there) even at the cost of the performance loss on the 32-bit x86. Whereas all BSD's (Free, Net and Open) just baulked at it and stuck with the historical BSD ABI for several more years to renege later on.

theresistor 4y ago

In this case, many of the divergences exist because the standard AArch64 ABI (AAPCS) wasn't finalized at the time that iOS had to lock its ABI. Several items are actually the standard version from pre-finalization versions of AAPCS, and couldn't be changed to match the standard because iOS binary compatibility was already locked in.

steve1977 4y ago

Disrespect of standards? As one of the founding members of Advanced RISC Machines Ltd back in 1990, Apple is rather behind those standards.