Disambiguating Arm, Arm ARM, ARMv9, ARM9, ARM64, AArch64, A64, A78, ... | Hacker News Reader

Disambiguating Arm, Arm ARM, ARMv9, ARM9, ARM64, AArch64, A64, A78, ...

nickdesaulniers.github.io

313 pointsmatt_d87 comments

So the ARM Architectural Reference Manual (the Arm ARM) defines the three architectural profiles: A, R, and M. I'm not even mad, that's amazing.

And Thumb is an ARM extension. Their naming is full of awful puns

Thumb-2 was internally codenamed Wrist. Because it's between ARM and Thumb

Tangentially related, at one point Palm gained ARM support: https://en.wikipedia.org/wiki/Palm_Tungsten

With ARM now in the data center, you can easily write an ARM REST server.

That would also allow you to do some curls to exercise those ARMs.

If you use an ARM software license, the license is administered by your local FLEX server.

You will look buffer for sure

That really had me laughing.

Old chap, this is Britain we are talking about.

All part of the Acronym-Reuse Model.

Apple platforms diverge from Arm’s ABI in specific ways.

...and so does Microsoft with its ARM64EC ABI:

https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-...

I've always thought it odd that a CPU manufacturer would specify an ABI, since that seems to imply preference towards certain programming languages and techniques which may or may not be ideal in all cases; Intel certainly didn't.

Intel probably wishes they did. That's because ultimately having code generally follow a common structure gives you as a uarch designer a bit more to work with wrt how RTL micro-optimizations affect your customers' code. Towards that end, the different AArch64 ABIs are pretty minor morphs when compared to the clusters that are x86 ABIs.

This statement confuses me.

There are two ABIs in common use on 64-bit x86. One is used on windows; the other is used everywhere else, and intel has been involved in its specification (I believe its current editor is an intel employee).

Most concerns relating to ABI specification can be dealt with pursuant only to architecture, not microarchitecture; minimising instruction or byte counts, say. And architectures have long lives, over the course of which microarchitectures may change quite a lot. You wouldn't want your ABI to be overfit to one particular microarchitecture.

Not to say that it's a bad thing for a processor or architecture vendor to supply a standard ABI. It's good to have cohesion and consistency, and furthermore, if you have designed an architecture, then you have (one really, really hopes) performed a lot of experiments to see what code for that architecture looks like, so you are in a good position to be specifying an ABI. But that's not to say a third party is per se in a worse position to be specifying an ABI.

And of course, stable binary interfaces are dying (and good riddance!), but that's a separate issue.

Yeah, they cleaned up x86-64, but x86-32 had three calling conventions on windows alone.

> I've always thought it odd that a CPU manufacturer would specify an ABI

Why?

It we all agree to use R13 as SP, the core designers can spend a few [hundred] extra transistors optimizing accesses to [R13 + offset]. Perhaps adding such logic for ALL registers is too costly?

If we all agree that R14 is the return address, the prefetcher might want to prefetch instructions there, so return is faster. The core probably cannot afford the transistors to do that for ALL regs

ARM (and most other chips) will work if you do not follow those conventions, but they might not perform as well.

Eg: aarch64 instruction "ret" takes a register param and you can use any reg you wish, but at least on some microarchitectures implementing the aarch64 ISA, it will be faster if the param is the X30 register, since that is the agreed-upon return address reg, and some silicon was spent optimizing this case

Why even call them R13/R14 then? Intel specifically assigned a stack and frame pointer on x86, and there are even special instructions to work with the former, and addressing modes for the latter (BP/EBP/RBP uses the stack segment). Interrupts and exceptions will also implicitly use the stack pointer.

It's odd because ARM seems to be trying to present itself as being a RISC, when the architecture appears to be slowly becoming something else. The allowable addressing modes with each instruction in A64 clearly shows this.

well, for example in ARMv7 and below, it was common to use LR(r14) ALSO for math during the function body if there was register pressure. So it does assist a little. And the instruction set encoding is much simpler if every reg is just ... a reg. No need for push and pop if you can store with predecrement and load with postincrement. And those stores/loads are useful ALSO for non-stack ops, if your compiler is clever. _At the time_ the design made good sense.

But in modern very-OoO cpus, you are right, and having SP and PC be GPRs is of little use and of non-negilible cost design-wise, which is why in aarch64, SP and PC are special and not GPRs like they were in ARMv7 and below. LR still is a GPR though

It's history, mostly. The very first Arm design didn't do anything special with r13 and r14, so using them as sp and lr was purely convention (you could have an upward growing stack in r0 if you wanted). The years roll by, and it turns out that in fact everybody follows the conventions, so it makes sense with cleverer hardware to optimise for r13-is-sp, and it's a reasonable tradeoff with Thumb to enforce r13-is-sp in return for being able to make the instructions smaller and save code size. The technical constraints and situation of 1983 are not the same as those of 2003 or 2023.

There was always one instruction that made r14 special: BL, branch with link. Both r13 and r14 are special for exception handling and SWI instructions, because they have extra versions in the register banks, specifically for the supervisor mode stack pointer and exception return address.

Oh yes, good points.

The Arm 32 bit EABI spec acknowledgements section credits 9 other companies for their "active support" -- most of them are or were toolchain vendors. You specify an ABI so that all the different companies who are writing and selling compilers can produce object files that work together, which makes it easier for customers to develop software for the CPU, which means you can sell more chips. Nobody will come and break down your door if you choose not to follow the ABI, of course, but if you want to interoperate with others you have that option.

And yes, there's an implicit bias towards C and C++ here, but that is just because that is the environment where enough toolchain developers and customers care about interoperability between different suppliers to make specification worthwhile.

Good old ARM naming schemes. I remember some amusement when I worked at TI and my team went from working on an ARM7-based microcontroller to an ARMv7-based microcontroller. (The ARM7 was an ARMv4 CPU, naturally.)

And now the Arm (Neoverse) V1 is Armv8

Timely, but not quite what I needed (unless I missed something in the article—pretty likely). I just spent a bunch of time setting up a Raspberry Pi 1 B with Alpine Linux, and it was surprisingly difficult to find the right strings of gibberish to get everything set up.

The Alpine packages are “armhf” and the last 2 letters I think mean it has hardware floating point support.

The kernel is armv6l and I still don’t know what the last letter is for.

Cross-compiling for it can be annoying, but I seem to be able to pass the CPU name directly (I don’t remember it off-hand, but it’s more easily Google-able) to get things to build properly.

I don’t really have a point, just venting…

> I just spent a bunch of time setting up a Raspberry Pi 1 B with Alpine Linux

But why? That’s ancient! I’ve got a few different models of Pi’s laying around and even the 3B+ ones feel old at this point!

The oldest one that I have is surely an RPi 1 Model B as well! Because it has dual USB ports and no more USB than that. Haven’t used this one for ages tho, but still have it sitting on my desk here.

Edit: Specifically, after looking at some more images and details online, the oldest mentioned Pi that I have in my possession seems to be a Raspberry Pi 1 Model B Rev 2.1 (UK) model.

It’s just what I had available. I wanted to see how much I could do with it. It’s surprisingly capable! But very slow.

Well, that’s still better than me. You putting your old Raspberry Pi to use, while me having my old Pi’s sitting unused just because the newer ones I have are faster :)

And meanwhile I have a couple old PowerPC macs that I plan to put to use, which may at this point be slower even than the RPi 1 B I have and am not using :p

i like the 3b+ for its reduced current consumption, you can just use any old 5v2a power supply with it

Sure, if you don't mind constant undervolting. In my experience the only way to get a 3b+ to run reliably is to power it directly from the 5V header pin.

I haven't had any problems running one 24/7 for half a decade now. I suppose it depends on your peripherals and load though.

> The kernel is armv6l and I still don’t know what the last letter is for.

ARM is bi-endian. I'm pretty sure the 'l' means the kernel was compiled to be little-endian.

I probably should have thought of that, thanks!

So what you're saying is, it's bi-endian because you have two arms, and this is the Left one?

Yes:

> elf32-littlearm, and elf32-bigarm

Ah, in my rough draft I do have a section on this! But I cut it because hardware support for floating point on ARM deserves its own post.

Keep an eye out for the follow up then.

Touché!

For the record, I was complaining about the diversity of ARM targets (as viewed by someone who wants to have to know as little about it as possible, while still getting things to work), and not about your article!

Are you familiar with RISCV? :^)

FWIW, the Raspberry Pi 1B is an ARM11, which is why you are getting and booting an ARMv6 kernel. v6 is the architecture; the "l" at the end of "v6l" indicates it's little endian.

As for "armhf" it is a description of the the ABI, and the "hf" means what you said, that the hardware supports floating point operations. I'm slightly confused as to how armhf could work on the ARM11 on the Pi 1 and Zero generations, as AFAICR it targeted v7 onwards.

Ah, it seems that Raspbian built for ARMv6 but still used the ABI tag "armhf", how confusing; I guess Alpine has done something similar.

https://wiki.debian.org/RaspberryPi#Raspberry_Pi_OS_.28forme...

"hf" is targeted at v7 and newer in Debian but I don't think it's for any technical reason. Raspbian is mostly just Debian recompiled for ARM v6 with hardfloat and it works just fine.

ARM11 has an FPU. The FPU is particularly slow to copy back and forth to the integer registers. This the raspberry pi people support an ARM11 core with armhf ABI, albeit limited to the VFPv2 FPU instruction set.

The 'hf' not only refers to the presence of a hardware floating point unit, but also that the floating point function arguments are passed in floating point registers in the ABI. For interwork with precompiled binaries, the full ABI support assuming hardware floating point trailed behind the simple presence of an FPU for a surprisingly long amount of time. For a real long time, the asm would be crazy, passing floating point arguments into the integer registers at every function call boundary, just to pass them back into the FPU registers to perform any work on them.

ABI compat: yet another price we pay for the legacy incremental compilation hack known as linking.

I think I'm more confused now than I was before.

Same!

I don't want it to be lost on others so I'll explain it (this kills the joke, unfortunately), ndesaulniers is the author of the linked article.

Ha, I should clarify that I'm not more confused because the article didn't do its job, but because it did it perfectly. I had no idea at least half of those arms existed.

Marketing successful [x].

Sometimes I think they work against humanity.

I didn't know I didn't understand arm versions. Now I do know.

So when I run “uname -m” on Mac it says “arm64”, but running it in a docker container on the Mac it says “aarch64”. Doesn’t seem like everybody is in agreement.

That was the first thing I hit when compiling the Linux kernel on Macos!

It's traditional; before that we had amd64 AKA x86_64 AKA x64

Docker on other-than-Linux platforms runs in a Linux virtual machine, because there's no containers without Linux. Running uname in a container then reports what you would see in Linux, not what the host reports.

I was surprised to find out that Docker now installs as a VM by default even on Linux, unless you choose to install the Docker Engine manually.

https://docs.docker.com/get-docker/

Interesting, that's also news to me. I wonder what the purpose for that is? I suppose it's possible to control the kernel version and cgroup configuration more easily that way, but I imagine networking and filesystem access becomes more complicated.

They go into the details quite nicely in their documentation [1].

A more cynical take would be to wonder if it has anything to do with their steps trying to monetize Docker Desktop. This move puts the same stack in use with Linux, maybe giving them monetization on Linux as well. (Not that there’s anything wrong with that. You can still use the Docker Engine freely on Linux if you want. )

[1] https://docs.docker.com/desktop/faqs/linuxfaqs/#why-does-doc...

This is Docker Desktop. They have an official explanation for it: https://docs.docker.com/desktop/faqs/linuxfaqs/#why-does-doc.... You can still install the docker engine directly if you want.

No that's not correct. Docker runs on Linux.

Docker _Desktop_ is an indirection tool, a glorified network stitcher, that runs VMs to make it appear like you are running Docker on other systems (Win/Mac). Docker _Desktop_ installs a VM by default, likely in a bid for consistency across platforms.

On Linux you should not be installing Docker Desktop, only Docker Engine.

Windows has containers, and Docker runs natively on them.

To fit into the ecosystem, Windows has traditionally exposed them via Docker CLI endpoints.

This is changing now with kubernetes moving away from Docker as dependency, and other tooling is becoming available to manage Windows containers.

Windows has containers? How does that work?

I know Windows has WSL and Docker Desktop, but they both run a Linux kernel in a hardware accelerated virtual machine. I wouldn't call that native.

Containers isn't a Linux thing, in fact the first time I used containers in production, was in HP-UX in 1999, with HP-UX Vaults.

In the case of Windows containers, WSL is only there to keep Docker management tools happy, and for Linux containers

Windows containers infrastructure is based on Windows Jobs, and they are exclusive, either you run Docker in Linux mode, or you run it talking to Windows containers and this is on way out since containerd no longer needs it.

https://learn.microsoft.com/en-us/virtualization/windowscont...

My point is mostly that the article implies Apple, Microsoft and Linux (or at least Linus) agree on using the term arm64, but the agreement doesn't seem to be too deep given that uname reports different values.

Btw in updating a Docker image to support multi-arch, I sometimes had to download binaries named with arm64 in the name, and sometimes with aarch64 in the name. But the previous version had the same issue with amd64 vs x86_64, so it's not a new issue.

This is useful context but seems incomplete without direct links to the gcc docs for both arm and aarch64.

For your perusal. :)

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/ARM-Options.ht...

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/AArch64-Option...

I had a reference to https://sourceware.org/binutils/docs/as/AArch64-Extensions.h... that I cut from my rough draft that I do miss.

This has cleared up a lot of confusion for me!

Slightly tangential, but can people recommend a good site for finding hardware available to purchase for specific ARM versions? In particular, when hardware implementing a new ARM version (e.g. 8.5 or 9) becomes available, where should I be keeping an eye on?

Alternatively, what manufacturers are usually the first to produce new ARM hardware?

If you're looking for chips / SOCs which implement a given arch, this Wikipedia template from the article is pretty good: https://en.wikipedia.org/wiki/Template:Application_ARM-based...

If you want to find a consumer device which implements a specific arch, you can take the list of SOCs from above, and select them in "Chipset" in GSMArena's search: https://www.gsmarena.com/search.php3?

AArch64 SoC features:

https://marcin.juszkiewicz.com.pl/download/tables/arm-socs.h...

https://github.com/hrw/arm-socs-table

Bookmarked (and appreciated!) solely to let me be lazy and send a link instead of repeating the same speech to other devs.

That's why I wrote it!

What’s an execution state? From my reading of this post, it doesn’t seem to be an architecture.

Most modern OSes (recent MacOs excluded) are 64-bit, but can run both 32 and 64-bit programs.

When such OSes run a 64-bit program, they are in 64-bit execution state and when they run a 32-bit program, in 32-bit execution state. Basically, the processor switches execution state depending on what is being run, and in a way "emulates" a 32-bit processor by restricting registers and so on to be compatible with the 32-bit arch.

That's just the start of it. On Arm you also have the secure state and exception level.

  Non-Secure EL0 is user space, with limited access to system registers.
  Non-Secure EL1 is kernel space with more access to system registers.
  Non-Secure EL2 is hypervisor space with more access to system registers.
  EL3 is the secure monitor.

I'm not sure what the secure states ELs can do, or if they have the same 3 ELs available as the non-secure side. Likely not. I've never used them, but I think the secure state is described as though intended for a set of micro-services that the Non-Secure levels can send requests to.

There are extensions allowing Hypervisor EL2 to be a Secure state. A secure hypervisor may be able to manage secure and non-secure kernels.

Arm allow various levels to not be implemented, supporting weird combos, like EL2 and EL0, without an EL1.

The current state can also control what you're allowed to do with peripherals, like the interrupt controller. Even if provided access to the GIC's full register set, code running in a non-secure state cannot reconfigure or induce a secure interrupt. Any such requests will be ignored. Secure and non-secure accesses to memory may read from entirely different RAM chips.

...The execution state gets kinda complicated.

> I'm not sure what the secure states ELs can do, or if they have the same 3 ELs available as the non-secure side. Likely not. I've never used them, but I think the secure state is described as though intended for a set of micro-services that the Non-Secure levels can send requests to.

> There are extensions allowing Hypervisor EL2 to be a Secure state. A secure hypervisor may be able to manage secure and non-secure kernels.

So the extension isn't to allow a normal EL2 access to secure state, but instead to run a hypervisor to allow several SEL1 secure OSs. It wouldn't be weird to run one hypervisor in SEL2 and another in EL2 with SEL2 multiplexing a few trusted OSs and EL2 multiplexing several OSs as a standard heypervisor. Both would run on top of the EL3 monitor.

don’t forget arm26

Do you mean ARM926? That was a very common core in dumbphones.

I don't think arm26 was a typo: https://en.m.wikipedia.org/wiki/26-bit_computing

Check the parent's username.

Almost certainly not.

https://en.wikichip.org/wiki/arm/26-bit_architectures

https://en.wikipedia.org/wiki/26-bit_computing

Flags, processor mode, and the PC (24-bit) were kept in the same 32-bit word. That made it cheaper to store/restore on interrupt and, boy, did they want interrupt handling to be fast!

Combined with the requirement for naturally aligned instructions, this gives the original ARM a 26-bit address space for code. They chose to make that the address space for everything -- so the address space was 64MB.

The ARM926 came much later.

If you are Sophie, I'd just like to say thanks.

Yes indeed the entire world relies on ARM products ! Britain found a better way to conquer the world TIL ...

Just to add my thanks too. I saw Steve Furber do a presentation about the first ARM CPU in 1986, never thought I’d be typing this on an Arm powered device 37 years later.

Having read all that I am now even more confused and ambiguated.

Technical writing is hard.

And they say it's Microsoft that is bad at naming their products.

They are.

I though ARM is an acronym of ARM Rephrases Meanings.

Why would someone name it ARM64 when it looks so similar to AMD64. I'm sure that has caused some confusion or things to break (or will do so at some point). Naming things is a usability issue.

I have fixed this exact typo before. The visual similarity is annoying.

https://github.com/dotnet/runtime/commit/1f4835129630f12008d...

Reply on news.ycombinator.com