Dropping 32-bit hardware from newer phones breaks apps with 32-bit binary components such as libraries.
How badly did they have to fuck it up for it not to be backwards-compatible? Isn’t it trivial to just pad out the upper (or whatever, given endian-ness) half of the register with zeroes?
I’m so glad you asked because I specialize in instruction set architectures of all kinds in my day job. You can’t simply pad larger registers. The instructions themselves, the native binary code that the processor executes has changed. If you want to execute different native code, you need different hardware.
The relationship between 32-bit Intel and 64-bit Intel is a very generous one, providing lots of opportunity for backwards compatibility. You can’t buy a 64-bit only Intel processor for example. Here, when I write Intel I mean x86, not necessarily the manufacturer Intel. Even processors marketed as exclusively 64-bit must contain the 16 and 32-bit modes. Therefore, running 32-bit code on a 64-bit x86 family processor is a relatively simple task in principle. You enter the mode that you need, and the instructions have many similarities.
64-bit arm (actually aarch64 or Armv8) is remarkably different from 32-bit (armv7). Firstly, there is no expectation that 32-bit mode will be available. It saves space, power, and area not to include the support, and all of these factors are especially important in the mobile realm. Given that the binary instructions are so different, there’s very little to be gained by combining support for the two. They’re basically different languages.
Mostly Eastern handset manufacturers still include the 32-bit hardware because third party app stores in those countries frequently offer 32-bit binaries. Even then, it’s relegated only to the low or middle performance cores. Vendors targeting Western markets prefer to leave it out so they can invest more heavily on the 64-bit side and obtain better performance for most apps.
However, as the article shows, this is changing. We’re starting to see a shift to 64-bit only hardware and instead using creative software techniques to bridge the gap. The alternate solution is to translate the code into a form that the hardware does understand at run time, at a cost of some performance and memory.
How badly did they have to fuck it up for it not to be backwards-compatible? Isn’t it trivial to just pad out the upper (or whatever, given endian-ness) half of the register with zeroes?
I’m so glad you asked because I specialize in instruction set architectures of all kinds in my day job. You can’t simply pad larger registers. The instructions themselves, the native binary code that the processor executes has changed. If you want to execute different native code, you need different hardware.
The relationship between 32-bit Intel and 64-bit Intel is a very generous one, providing lots of opportunity for backwards compatibility. You can’t buy a 64-bit only Intel processor for example. Here, when I write Intel I mean x86, not necessarily the manufacturer Intel. Even processors marketed as exclusively 64-bit must contain the 16 and 32-bit modes. Therefore, running 32-bit code on a 64-bit x86 family processor is a relatively simple task in principle. You enter the mode that you need, and the instructions have many similarities.
64-bit arm (actually aarch64 or Armv8) is remarkably different from 32-bit (armv7). Firstly, there is no expectation that 32-bit mode will be available. It saves space, power, and area not to include the support, and all of these factors are especially important in the mobile realm. Given that the binary instructions are so different, there’s very little to be gained by combining support for the two. They’re basically different languages.
Mostly Eastern handset manufacturers still include the 32-bit hardware because third party app stores in those countries frequently offer 32-bit binaries. Even then, it’s relegated only to the low or middle performance cores. Vendors targeting Western markets prefer to leave it out so they can invest more heavily on the 64-bit side and obtain better performance for most apps.
However, as the article shows, this is changing. We’re starting to see a shift to 64-bit only hardware and instead using creative software techniques to bridge the gap. The alternate solution is to translate the code into a form that the hardware does understand at run time, at a cost of some performance and memory.