I’m about to step into the wonderful world of ARM Linux. I work with ARM32 as an embedded developer profesionally (Cortex-M3 specifically) so I’m not a complete newbie. But I’ve never used ARM64, and I’ve never used it with a desktop OS. So I’m doing my research, as one does, to know roughly what I’ll be dealing with.

I have a few questions regarding backward compatibility and architecture-naming. Maybe you specialists out there could shed some light.

From what I could find, I understand the following:

  • arm64 and aarch64 are the same thing: the former is what Linus likes to say while the latter is what ARM calls their own stuff.
  • arm64 / aarch64 really mean “compatible with ARMv8” as a least common denominator, meaning ARMv8.x-y (x being the extension, y being A for application or R for realtime) will run it, just without taking advantage of any extension or realtime instructions.
  • ARMv9.x will run arm64 / aarch64 kernels and applications, as it’s (supposedly) backward-compatible with ARMv8, just without taking advantage of the ARMv9 ISA.
  • If I want to create arm64 software that takes advantage of this-or-that extension or realtime instructions, I have to compile it in explicitely. I’m not sure if gcc handles special instructions, I haven’t checked yet, but I suppose it does since it knows about the Thumb mode for instance.

Do I understand correctly?

If I do create some software that relies on extended ARMv8 or ARMv9 features and I want to release my software as a package, how should I name the package’s architecture? Is there even a standard for that? Will it get rejected by the package managers of the few ARM distros out there, or will it be recognized as a subset of the wider arm64 / aarch64 architecture?

  • @TCB13
    link
    English
    1120 days ago

    Yes, you did. “aarch64” and “arm64” are the same thing. AArch64 is the official name for the 64-bit ARM architecture, but some people prefer to call it “ARM64” as a continuation of 32-bit ARM that is also known as “armhf” and “armv7h”.