Aarch64 support added | Hacker News Reader

Aarch64 support added

mail-index.netbsd.org

82 pointsalgorithm31422 comments

Honest, stupid question:

On x86/x86_64 the major advantage 64-bit mode brings to the table is support for more than 4 GiB of RAM. You get more registers and (IIRC) better support for position independent code, OTOH, pointers get bigger which may cause worse cache utilization. My personal experience after running both a 32-bit and a 64-bit system on the same machine was that performance was pretty much the same; either for me, performance was limited by other factors (cough I/O cough), or the advantages and disadvantages of 64-bit mode canceled each other out (or the difference was too low for me to notice).

On a device like the Raspberry Pi 3 (I happen to have one at hand), where the amount of RAM is a) fixed and b) less than 4 GiB, what advantages might a 64-bit OS offer?

EDIT: Thanks for all the answers!

A few benefits:

1. For DSP / image processing, 64-bit SIMD allows you to operate on twice as many elements as 32-bit SIMD

2. For normal computing, you get 31 64-bit registers instead of 15 32-bit registers (essentially 4x register memory)

3. 128-bit floating point

I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent. The issue is that most code is not able to take advantage of SIMD, and almost all code is not register limited by any stretch, particularly as people tend to write such small functions, and we don't have calling conventions that can try to build register windows (like, "this is an A function that uses this subset of registers while this one is a B function that uses this subset of registers, so if we call a B from an A we don't have to save anything") combined with the top of the stack often being a virtual construct in the CPU anyway (mapped to virtual registers). With the ability for 32-bit ARM to compile stuff to half the code size (due to the Thumb variants), which lets it use half the limited instruction cache space and load faster from disk, it just isn't a very interesting upgrade. Oh: and programs tend to use a lot more memory, as now all of their pointers are twice as big. Some of these downsides are mitigated by the ability to play tricks like tagged pointers (you can't actually use all 64 bits for an address: only 48 or 52 or something are actually wired to the address bus), but except for specialized stuff (where the SIMD and floating point benefits really matter), the only real benefit is "the address space is larger" (a truly useful thing, FWIW, making it much easier to work with large files). (Oh: and it is easier for me to reverse engineer your code due to more useful invariants in the calling conventions ;P. This part makes me really happy.)

> I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent.

I think that's true on an RPi with it's super gate constrained, in-order core, but AArch64 was really designed to make OoOE cores with complex prediction a lot easier.

> 1. For DSP / image processing, 64-bit SIMD allows you to operate on twice as many elements as 32-bit SIMD

I think this is very much wrong. You do get more SIMD registers, but both 32-bit and 64-bit ARM have 128 bits wide SIMD registers. Same number of elements per instruction.

> 2. For normal computing, you get 31 64-bit registers instead of 15 32-bit registers (essentially 4x register memory)

Almost right. 14 vs 31. On 32-bit ARM, R13 is stack pointer, and R15 is PC, program counter. 64-bit ARM doesn't have PC mapped to register file anymore.

> 3. 128-bit floating point

As far as I know, AArch64 does not have 128-bit floating point. Nor would it really be useful except in very rare circumstances.

64-bit ARM doesn't have PC mapped to register file anymore.

Interesting. Does this have any effect on debugging?

Not really. You can debug i386 code just fine, right? It also doesn't have PC mapped to register file.

* Memory-mapping files larger than ~2GB

* Vastly larger address space -> better ASLR

I wonder how the x32 ABI performs. The x32 is a Linux ABI were amd64 is used, but pointers are 32 bit. I'm still wondering if some company is using it.

Now that we are at it, I'm wondering if there is something like x32, but for Aarch64? AFAIR Aarch64 is nothing like amd64 is for x86, but it could still be just 32 bit pointers, but all the registers.

https://en.m.wikipedia.org/wiki/X32_ABI

AArch64 was def designed for this too. You can use the w registers (the lower 32 bit halves of the GPRs) as load/store arguments, which pretty much only makes sense in an x32 like ABI.

I used the x32 ABI at a previous job, for an ARM-on-x86 emulation project. The x32 ABI outperformed both x86 and x86_64 for that purpose. It wasn't a huge margin, but it was enough to make us want to use it over x86_64.

I wish I still had the performance data for that, so this would be more than an anecdotal comment.

Physical ram is different from virtual address space — the larger address space lets you map in large files (>3 gig). The ISA for aarch64 is also somewhat cleaner than armv7/thumb, etc.

Also while I can’t speak for low end isa implementations the high end ones are all substantially faster than the old 33bit archs. Both reference microarchs from arm itself and the custom designed ones.

32bit I mean. I’m fairly certain no one has made a 33bit arm variant yet :)

> where the amount of RAM is a) fixed and b) less than 4 GiB

32-bit ARM (like Cortex A7, A15, etc.) already supported 1 TB addressable physical RAM.

In addition to what everyone else has said, aarch64 is obviously designed to make OoOE cores simpler.

So you wouldn't necessarily see all the benefits in a gate constrained in-order core like in the RPi.

This. AArch64 is far more than a simple "ARM, but with 64-bit addresses" change, most obviously predicated instructions are gone (which is a big deal for OoOE) and exceptions are vastly simpler.

AArch64 has a lot of the "weird" parts of classic ARM removed. Predicated instructions are gone, the bizarre Java bytecode mode is gone, Thumb/instruction compression is gone. These makes the ISA easier to scale up to more sophisticated processor microarchitectures.

Um, support for more than 4GiB of RAM was never the main reason for 64-bit mode. x86 CPUs ran wih PAE just fine. The only reason why you think you needed 64-bit OS was because Microsoft decided to disable PAE on 32-bit Windows.

What do you mean? There is the /pae switch. Also isn’t each process limited to 4gb under 32bit pae

NetBSD peeps: if you want to play with UEFI and PSCI support, check out https://github.com/andreiw/RaspberryPiPkg

This is a 64-bit UEFI firmware for RPi3 that uses ATF for PSCI, and has USB, HDMI and SD card support. It has been successfully booting FreeBSD, SUSE Leap 42.3 and Ubuntu 18.04.

OpenBSD's also had arm64 support since 6.1, with 6.3 coming out early this month introducing SMP support.

https://www.openbsd.org/arm64.html

https://www.openbsd.org/61.html

https://www.openbsd.org/63.html

Oh, how times have changed and the tables turned. I remember time when NetBSDs claim to fame was its portability and wide architecture support. Now it's tailing the others.

Of course I understand why that is. I wouldn't be surprised at all if this port was result of less man-hours than it's peers, but the man-hours put into NetBSD are simply spread pretty thin.

Reply on news.ycombinator.com