This is true, but that last sentence is a doozy. The AArch64 ISA drops that stuff. The A7 CPU, which much remain compatible with legacy code, must not. So yes, a theoretical CPU would have a much easier design task, but in the real world we'll never see one.
And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. It's really not a meaningful design limitation to a CPU core implemented with hundreds of millions of transistors.
I would not be surprised if an iPhone without support for 32-bit apps came out within a few years. Apple has been pretty willing to break existing apps with iOS updates, so there's no real expectation that something which works today will continue to work indefinitely with no changes.
There is already the ARM "big.LITTLE" architecture which pairs fast high-power cores with slow low-power ones on the same die. In the future I could imagine that extended so that a subset of cores are 64-bit only.
As others mentioned, though, I don't think Apple will need to do that since they've got a closed ecosystem. They can just declare one day that they won't accept App Store submissions that don't include a 64-bit version and very quickly move the entire universe of iOS software. There will be some no-longer maintained apps that aren't updated but they can just say "Sorry, this app doesn't support iOS 8"
There are also binary-translation techniques like what they did with Rosetta in the PowerPC->Intel transition. This wouldn't need to be done on the phone; they could just do the translation once on the app-store side.
Not from Apple, maybe. I know there is at least one in the works for the server market.
> And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs.
You absolutely can implement a fast core out of almost any ISA (just look at IBM System z!) if you have sufficient resources. The point is that A64 is amenable to being made into a fast CPU without Intel-scale design effort.
ARM already has multiple-cycle instructions and variable clock rates. Why shouldn't they release a faster-clocked processor where every instruction in 32 bit mode takes 2 clock cycles?
And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. It's really not a meaningful design limitation to a CPU core implemented with hundreds of millions of transistors.