There are many CPU architectures out there, with the biggest ones being x86 and ARM. Having said that, AArch64 has probably flown under your radar. Even the fairly well-read tech enthusiast might have never heard of it, despite the fact that it's present in millions of devices. Well, the thing is that AArch64 isn't mysterious so much as it is a very confusing technical term. Here's what you need to know about AArch64.
AArch64 is ARM64, sort of
In short, AArch64 is the official name for Arm's 64-bit instruction set architecture (ISA) that was introduced with the Armv8-A update. It almost always refers to AArch64. It's not clear exactly why ARM64 is often used in place of AArch64, but part of the confusion seems to stem from two places. Part of it is because the 64-bit extension of x86 is x86-64, so naturally ARM's 64-bit extension should be ARM64. Apple certainly seemed to think so and referred to AArch64 as ARM64 until 2014. For most people, "AArch64 is ARM64" is a very satisfactory explanation.
If you want to get really technical, AArch64 isn't the ISA, but rather the execution state that allows ARM CPUs to use (and only use) the A64 instruction set of the ARMv8 ISA, which was first introduced with the Armv8-A architecture. If this sounds confusing, that's because it is. Even if you're familiar with computer architecture, this can be difficult to understand, so I'm going to explain this step by step.
So technically, AArch64 is a state, not an ISA, but nobody cares, not even Arm itself.
ARM is a family of related ISAs, and although different ISAs usually imply incompatibility, that's not strictly true. Different versions of the ARM ISA are called ARMv1, ARMv2, and so on, but these ISAs contain what are essentially sub-ISAs: A-profile, M-profile, and R-profile. The basic difference between these sub-ISAs is the minimum amount of instructions each one uses, with A-profile using the most and M-profile using the least. So, the ARM ISA is divided into individual versions such as ARMv8, and then those versions are further divided into different implementations of the ISA.
Armv8-A is the initial A-profile implementation of the ARMv8 ISA, which added two new things: AArch32 and AArch64. These are referred to as states or modes, and they allow ARM CPUs to access different instruction sets, with AArch32 containing the 32-bit A32 and T32 instructions, and AArch64 containing the 64-bit A64 instructions. For instance, if a processor is currently in the AArch64 state and wants to use A32 instructions, it has to change its state to AArch32. Additionally, in AArch64 mode, both the 32-bit and 64-bit registers are accessible, while in AArch32 mode only the 32-bit registers are usable. The most confusing part of all this is that all of these things are variably referred to as ISAs and even Arm (the company that develops the ARM ISA) is guilty of this.
But if we're being super technical, this is how it actually is: the eighth version of the ARM ISA, ARMv8, was first implemented with Armv8-A, which contains two states called AArch32 and AArch64. When a CPU is in the AArch64 state, it can execute 64-bit A64 instructions. So technically, AArch64 is a state, not an ISA, but nobody cares, not even Arm itself.
Why both 32-bit and 64-bit matter for ARM
So AArch64 is actually pretty complicated, and having to switch states just to use 32-bit and 64-bit instructions seems cumbersome. The thing is, support for both 32-bit and 64-bit was too important to pass up, so it just has to be this way. It really came down to two major issues: needing to support old 32-bit software, and pursuing modern, high-performance computing.
If Arm didn't include native support for 32-bit software in its first 64-bit ISA, it could have been a disaster because, put simply, nobody wants to rewrite code. If ARMv8 required everybody to write new software from scratch, it could have put the ISA into a death spiral, where nobody makes or buys ARMv8 devices because of a lack of software, and then developers don't make apps due to a lack of users, ad infinitum until Arm has to call it quits. So, 32-bit support was non-negotiable.
On the other hand, not implementing 64-bit computing wasn't an option either. Intel and AMD, the companies behind x86, had been using 64-bit architectures since the early 2000s for their amazing CPUs, though at the time there was no call for 64-bit ARM chips as phones didn't need them. But the invention of the smartphone changed everything, and everyone wanted their phones to do more stuff. Not only would 64-bit support help smartphones become more powerful, but it also opened the door for companies to make ARM chips for markets where x86 traditionally dominated, like laptops and servers.
Basically, this whole naming confusion arose from Arm needing to modernize its technology in response to changing priorities. Perhaps Arm didn't need to implement 64-bit support in this manner, but it did, and that's how AArch64 came about. Although AArch64 isn't an ISA, that's how most people use the term, for better or for worse.