back to article 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, …

  1. Mage Silver badge

    No 32 bit?


    Unless you are Apple.

    1. martynhare

      Re: No 32 bit?

      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.

  2. Torben Mogensen

    Makes sense

    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.

    1. diodesign (Written by Reg staff) Silver badge

      Old Arm

      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.


      1. heyrick Silver badge

        Re: Old Arm

        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...

        1. horse of a different color

          Re: Old Arm

          Ooh, hark at him with his 15 registers! In my day, we had A, X and Y and thought ourselves bloody luck!

      2. Anonymous Coward
        Anonymous Coward

        Re: Old Arm

        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.)

        1. gnasher729 Silver badge

          Re: Old Arm

          Conditional execution was on a critical path and made it harder to increase the clock speed. I would estimate that removing 32 bit allows you to increase the clock speed by 15% or so.

  3. alain williams Silver badge

    Presumably also less power usage ...

    No 32 bit instructions so less silicon. Less silicon so less power needed.

    1. Steve Todd

      Re: Presumably also less power usage ...

      Not necessarily. Most modern CPUs turn off the power to bits they aren’t using, so the whole 32 bit subsystem could draw no power while running 64 bit code.

    2. devTrail

      Re: Presumably also less power usage ...

      Unless you have a coprocessor that you can switch off when needed.

    3. Charlie Clark Silver badge

      Re: Presumably also less power usage ...

      This is more about: "Space on the die is a premium. Wouldn't this be better used by a CODEC or encryption module?"

    4. Mage Silver badge

      Re: Presumably also less power usage ...

      And how do you run the older programs that no-one is going to recompile? Maybe the author is dead.

      1. Silas S. Brown

        Re: Presumably also less power usage ...

        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.

        1. Anonymous Coward
          Anonymous Coward

          Re: Presumably also less power usage ...

          and of course, the native 64bit CPUs in a few years time will be much more powerful than the 32bit CPU's the 32bit software would have been written for. A software emulation will probably be quite viable.

      2. gnasher729 Silver badge

        Re: Presumably also less power usage ...

        "And how do you run the older programs that no-one is going to recompile? Maybe the author is dead."

        Apple has an answer to that. You don't. Maybe not the answer you want to hear, but that's the answer.

  4. devTrail

    Does it really make sense?

    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.

    1. Charlie Clark Silver badge

      Re: Does it really make sense?

      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.

      1. devTrail

        Re: Does it really make 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.

        1. Charlie Clark Silver badge

          Re: Does it really make sense?

          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.

        2. Anonymous Coward

          Re: Does it really make sense?

          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.

    2. Lorribot

      Re: Does it really make sense?

      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?

    3. gnasher729 Silver badge

      Re: Does it really make sense?

      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.

  5. Anonymous Coward
    Anonymous Coward

    More marketing drivel from a VP

    "“We’re moving away from thinking in terms of cores and CPUs to form factors and user experiences"

    Ok, well good luck putting form factors and user experiences on a circuit board and getting any processing to happen.

    1. Charlie Clark Silver badge

      Re: More marketing drivel from a VP

      Yes, that was an unfortunate bit of Strategy Boutique vomit…

  6. Binraider Silver badge

    Gearing up to take the fight directly to X86_64. And NVidia's mass production experience and marketing monster too.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like