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?
Pretty much. From v8.0 onwards all the extra features are indicated by id flags. Stuff that is relevant to kernel mode will generally be automatically handled by the kernel patching itself on booting up and in user space some libraries will select appropriately accelerated functions when the ISA extensions are probed. There are a bunch off advisory instructions encoded in the hint space that will be effectively NOPs on older hardware but will enhance execution if run on newer hardware.
If you want to play with newer instructions have a look at QEMUs "max" CPU.
Thanks!
Yeah okay, that sounds like how it's always been done. I don't know why I figured it would be any different with ARM. But that makes complete sense.