Hacker News Reader

Comment by chasil | Hacker News Reader

"Perhaps more critically, the new core offers exclusive support for only AArch64 – dropping 32-bit support altogether."

I don't understand why ARM wants to throw away AArch32/Thumb/Jazelle et al.

This really shouldn't be in a phone - a lot of Android apps bundle 32-bit binaries for various purposes, and they won't run on this CPU.

I can see why Fujitsu mandated AArch64, but my phone isn't going to be on the Top 500, and there were benefits to these old instruction sets.

View on HN

Binary compatibility is no longer a huge concern. By now only very old programs will require arm32 support and most current offers on any app store will have been recompiled for the latest and greatest (because software writers also want to look better on newer CPUs). Plus, if the new hardware is that much faster, you may not even need to pack native blobs.

Of the Raspberry PIs, only the 3rd generation is capable of AArch64.

Because of this, very few Linux distros supporting the PI are 64-bit (Oracle Linux is the only one that comes to mind).

There does indeed remain a large AArch32 community that cannot move, and they will never, ever cross this gulf.

A new chip not supporting arm32 does not prevent software for being built for the platform. While there are enough users, the distros will be maintained.

I highly doubt that ARM is making decisions for the Cortex X3 core design on the basis of the Raspberry Pi market

Emulation ought to suffice for support of programs compiled for 32 bits.

Barely any updated Android app has 32 bit binaries. You can't even submit an app on the Play Store if there's no 64bit version since August 2019.

There are also benefits to cleaning up silicon. Eg: less transistors per core can mean more cores or less power or both.

If this were the case, then it would be better still to design a totally new instruction set.

Why cling to any remnant?

AArch64 is, effectively, a totally new instruction set. It was designed to allow for fully regular decoding, unlike AArch32 & Thumb, which is a big part of why getting those off of the chip is a big win – it's not just the decoders you clean up, you can now make your pipeline and speculation deeper because you can peek N instructions into the future without having to decode the N-1 instructions in front of it first to figure out where the Nth instruction lies. That's part of why you see AArch64-only designs like this and the A12+ cores with much larger reorder buffers.

Reply on news.ycombinator.com