Heads up: From 2022, all new top-end Arm Cortex-A CPU cores for phones, slabtops will be 64-bit-only, snub 32-bit Arm has set the date from when its high-end smartphone and laptop-grade Cortex-A processor cores will go fully 64-bit only. And that date is some time in 2022, when Arm is set to unveil its CPU design code-named Makalu that we'd like to guess is the Cortex-A80. Subsequent top-end Cortex-A cores will also be 64-bit only, …
ARM isn’t known for rich backwards compatibility, unlike x86. Dumping ARM32 support is great in this situation because mobile platforms are also not known for backwards compatibility, Linux isn’t known for its adherence to backwards compatibility (beyond the kernel<->userspace boundary) and it gives Microsoft one less excuse to create a legacy mess before they even start.
I loved the old 32-bit instruction set when I had my Archimedes and A5000 home computers, but over time the instruction set accumulated so much baggage that it became a mess. So I'm fine with a 64-bit only ARM. Nearly all modern applications use 64-bit only, so support for the 32-bit ISA is just extra silicon area that could better be used for something else.
Sure, it is a drag that future Raspberry Pis will not be able to run RISC OS, as this is (still) mainly 32-bity assembly code. But RISC OS, for all its qualities, will not amount to anything other than a hobby system until it is ported to a high-level language (such as Rust) and made more secure. Even as a past user of RISC OS, it was not the OS core that I loved -- it was higher-level details such as the GUI, the built-in apps, the font manager, the file system (with file types and applications as folders), and the easy-to-use graphics system. These could well be ported to a more modern OS kernel.
Ex-A5000, A3020, RiscPC user/owner here. I learned assembly programming on ARM26 then ARM32 (then x86 etc).
I met a few of Arm's Cortex-A designers around the launch of the A76, which was Arm's first step to 64-bit-only. I was surprised by the rolling of eyes when I mentioned the nice bits of ARM32. It was clear they just wanted to deal with the more RISC-y ARM64.
I got the impression some of the old guard at Arm, and some of the early designers who had moved on, had made their feelings known that ARM64 wasn't, in their opinion, 'real Arm'. Today's engineers, who were working away on ARM64, were fairly hurt by that.
It seemed the ARM32/64 was more than just an ISA split; there were internal politics and philosophies attached, too.
C.
ARM hasn't been "real ARM" since they got rid of
LDMVSIA R13!, {R0-R12, PC}^
In other words, a complete conditional state restore (including mode and flags) in a single instruction. There was an elegance in the original design, to which three decades of cruft has accumulated.
Mine's the one with the RISC OS 2 source code in the pocket...
The loss of conditional execution of all instructions has ruined ARM for me. Combined with being able to control when the status register was updated made it such an elegant instruction set.
Writing ARM code back in the late 80s/early 90s was the most enjoyable time I've ever had as a programmer. (I've made lots of cool stuff since then, but back then it was really fun.)
Hopefully by means of an emulator. Less efficient than hardware, true, but if few users need to run historical applications then I for one would be happy with an emulator instead of taking up everyone's chip space whether they use it or not. As long as there will be such an emulator.
If the problem was that the instruction set was outdated that would make sense. But if we keep talkig about 34 vs 64 bit the question is how many apps actually need 64 bits? I guess that most of the smartphones don't even have enough memory to serve apps that would take advantage of the difference and that won't change for a while, I mean that a smartphone may have more than 4 GB of RAM, but it could not allow a single app to use all the memory.
If the problem was that the instruction set was outdated that would make sense.
This is indeed what the article says. Support is being dropped because all code nowadays is compiled so there is no need for hand-crafted assembly, no matter how efficient it might be. ARM never had the same problems with 64-bit that x86 did, but rationalisation for the silicon being produced now does make some sense.
Maybe. But if it was outdated why it happened? Why put all the resources on the 64 bit line? Killing the 32 bit version with all the apps means also killing the possibility of making no frills models designed to make the best of a battery charge. 64 bit is an overkill on current smartphones and it will probably be so for another 5 years or more.
64 bit is an overkill on current smartphones
That's debatable. We're really talking about industrial rationalisation rather than the benefits of particular architecture. The improvements in architecture and manufacturing processing are significant and probably dwarf anything that can be gained by reducing the footprint of the code. Plus, compilers nowadays can produce code that is demonstrably more efficient (for the relevant architectures) than anything you could write by hand. But the main thing is, it doesn't really matter about the CPU: smartphones for the last few years are encoding 4k with HEVC in realtime using hardware acceleration. Likewise encryption is handled largely by the silicon. This saves much, much more power than writing more efficient CPU code. And this is what people do with their phones: they record and watch stupid hi-res videos that they share over 2x (transport + network) encrypted connections. They don't have to, but they still do.
If the 29 bit instruction set was viable long term the 32 bit instruction set wouldn't have been developed.
If the 32 bit instruction set was viable long term the 64 bit instruction set wouldn't have been developed.
ARM is trying to craft a more modern assembly language for the limited number of applications that still need to program in assembler (and the need to do that is becoming increasingly unjustifiable).
If 32 bit developers really want to live in the past, they can always develop an emulator.
A true 64 bit processor is not just about addressing memory.
AMDs x64 extensions brought only the ability to address extra RAM natively and is not a proer 64 bit architecture, its pretty much all 32 bit uner covers, Intel did go the full 64 bit path with IA64 but there was little uptake, Windows and SQL support died after about 4 years and there was a big spat between HP and Intel over new versions and support. I think only HP/Open VMSreally ever uses it now and VMS is moving to Intel x64.
It would be good to see Intel have a nother stab at a true 64 bit processor but i fear it is not in their mindset, AMD dont really have teh push to implement such a thing and are a licesee of ARM anyway so it is likely they will just make 64 bit ARM processors for servers and PCs for Windows and Linux. With VMware and Windows both coming in ARM flavours along with Linux, you have wonder where Intel will go?
Situation on an iPhone (or MacOS): if you have only 32-bit apps then you will pull 32 bit versions of many frameworks into RAM. If you have only 64-bit apps you pull the 64 bit versions. If you have just _one_ app that is different you need twice the RAM for two versions of frameworks. So it’s much cheaper if that one app that doesn’t really need 64 bit is compiled as 64 bit.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
