7 ms·

ARM adopts 64-bit architecture

113 points by codedivine 15y ago

nknight 15y ago
Is there any backstory on why this is only happening now? The address space situation is already borderline in some areas of ARM usage, and cell phones are about to break 1GB of physical RAM (if some haven't already?). Seems like this is a couple years overdue to have anything close to a comfortable margin.
- mbell 15y ago
  The instruction architecture is irrelevant to the issue of address space. The Cortex A15 can already address up to 1TB of memory.
  - 0x0 15y ago
    Well, even 32bit x86 can address more than 4GB memory, but at least there you have to use horrible hacks like PAE. When the native data size is smaller than the address space, taking advantage of the full address space and working with large data sets becomes a hassle.
  - nknight 15y ago
    No, it can do glorified bank-switching. That's not an increase in address space, it's a hack that assumes applications will still keep their memory usage to no more than 2-3GB.
    - mbell 15y ago
      Its not bank switching, its the MMU mapping the 32bit virtual address space of each process to a much larger physical address space. You are right that each process is still limited to 32 bits of virtual address space but bank switching has nothing to do with it.
      - nknight 15y ago
        Having extra hardware to help speed it up doesn't stop it from being bank switching. That is its essential nature, it doesn't matter how heavy the lipstick is.
      - CountSessine 15y ago
        Having extra hardware to help speed it up doesn't stop it from being bank switching. That is its essential nature, it doesn't matter how heavy the lipstick is. By that same logic, all of paged memory management is bank switching. I might also point out that current x86 CPUs map 64-bit addresses into 43-bit physical addresses using pages. Is that reverse-bank switching? It's purely coincidental if your CPU was designed to map N-bit virtual-space pointers into N-bit physical-space pointers. It's much more common, both now and historically, to map from N-bit to M-bit. There is no hack here.
        mbell 15y ago
        Its worth mentioning also that x86 64bit CPUs still use PAE, in fact they have to, its mandatory in long mode ("real 64 bit mode"). Additionally the version of PAE used in 64 bit mode is an extension of the original 32 bit PAE, adding an extra directory layer to support up to 52 bits of physical address space. Although i don't think any processor has implemented more than 48bits of address space so far.
  - masklinn 15y ago
    Oh? How does it handle this? Something similar to PAE? To PSE? Explicitly using cooperative coprocessors? A completely different scheme? Also, isn't it relevant to process-addressable (virtual) memory? Barring explicit APIs such as AWE. As far as I know, ARM registers are 32b so a process should not be able to load data from an address higher than the 4GB mark (in its virtual memory), am I wrong?
    - mbell 15y ago
      Two separate issues, memory per process (which is limited to 32bits of address space) and total physical address space available to the MMU. It is similar to PAE in fact ARM calls it LPAE.
- gecko 15y ago
  I'm not entirely sure I agree with you. 1. Cell phones may cross over the 2 GB boundary soon, but ARM can already comfortably address terabytes of RAM through segments, as mbell notes. At worst, we're limiting individual applications to under 2 GB of RAM--not the end of the world. 2. While being able to address 64 bits at once is useful for some computing tasks, *most* of those (scientific computing being a biggie, but also some parts of video editing or sound mixing) just aren't ones people currently do on a cell phone. They likely will eventually, but the hold-up there is as much about getting the data onto the phone in the first place as actually doing anything significant with it. 3. Adding 64-bit wide paths adds a *lot* of silicon for something that would currently not get used at all, and in the future won't get used much for quite some time. More silicon means a shorter battery life and more heat--not exactly what you want in a cell phone. Look at how much effort ARM's going to in big.LITTLE just to let them go superscalar, let alone 64-bit. 4. Finally, the on case where you might get good benefit--games--are better served through GPUs and ARM's existing NEON instructions, which already work on I believe 128-bit-wide values. So those are all the reasons why I don't see the lack of 64-bit ARMs right now as a real problem. And, indeed, if ARM were only getting used in cell phones, I wouldn't honestly see a pressing need to go to 64-bit chips, period. But ARM wants to move into servers, and there, the situation's obviously very different. 64-bits is a no-brainer for any moderately sized database, and that's where I suspect ARM really needs this ISA. But those will take a few years to build and gain acceptance, anyway; they've got time.
  - anamax 15y ago
    > Adding 64-bit wide paths adds a lot of silicon for something that would currently not get used at all, and in the future won't get used much for quite some time. I can't find the quote, but John Mashey said that adding 64 bit support to MIPS processors cost something like 5% area. Datapaths and architectural registers really aren't that expensive in area or power. It does takes more power to move 64 bits across the pins and 64 bit addresses take more space. I suspect that those factors are far more important wrt battery and cell phone cost than the processor costs.
ricw 15y ago
My prediction: once this architecture is in the release channels, Intel is out of them. In a matter of years, Intel will be the dinosaur of microprocessors. Unless Intel also (re-)embraces ARM. Its simply a matter of price and configurability. ARM is simply unbeatable when it comes to price. Let alone energy efficiency. Its time to short Intel shares..
- luu 15y ago
  ARM is unbeatable in terms of price right now, but that's because they have much smaller parts that are much cheaper to produce. What makes you think that will still be true if they want to approach the performance of mainstream Intel parts? Historically, low-end parts have managed to kill high-end parts by selling in larger volumes and amortizing their fixed costs over a larger base. ARM sells in huge volumes, but how is selling $1 embedded chips going to help them amortize the cost of their high end stuff? Decades ago, doing that sort of thing would helped Intel fill up their idle fab time while competitors like DEC struggled to pay for their fabs, but ARM has never owned its own fabs, and selling completely different low-end parts doesn't really help amortize the cost of masks, post-silicon debug, etc. of their high end parts. I'm also skeptical that ARM will retain its power:performance advantage if it tries to scale up performance to match low-end mainstream Intel parts (e.g., core i3). The main reason ARM has better performance:power is that there are diminishing returns to performance. Another is that Atom is a new product line, and Intel doesn't have much experience trying to optimize for low-end parts. That won't be true going forward. Yet another transient advantage ARM has is that Intel uses a high performance process, but they've said that they're going to have both a high performance and a power optimized process in the future. If anything, Intel's process wizardry should give them an advantage there, once they decide to push it. What other inherent advantages does ARM have over x86? It's a PITA to decode x86 instructions, but the ARM instruction set isn't very nice, either (e.g., look at how they ran out of opcode space, and overlayed some of their "new" NEON instructions on top of existing instructions by using unused condition codes for existing opcodes). I wouldn't bet against ARM but, if they win, it will be because of the usual reasons: better marketing, better business practices, and better engineering, not because there's some inherent advantage that lets them be cheaper than Intel. And, by the way, the configurability advantage you mention actually hurts them in terms of cost, by increasing the fixed cost per part.
Symmetry 15y ago
This link has a bit more information. http://www.arm.com/about/newsroom/arm-discloses-technical-details-of-the-next-version-of-the-arm-architecture.php http://www.arm.com/about/newsroom/arm-discloses-technical-de... I wonder how these two new modes will relate to existing modes like Thumb2?
- DiabloD3 15y ago
  I would not be surprised if they made a Thumb32 to match Thumb. Its a rather useful mode for certain kinds of programming from what I've heard from coders on ARM platforms I know.
- brigade 15y ago
  Even more information: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf http://www.arm.com/files/downloads/ARMv8_Architecture.pdf The answer is that there is only one 64-bit ISA, but all current 32-bit modes are still supported.
  - Symmetry 15y ago
    Yeah, I just found that this morning. I'm sort of leery of the move to 32 GPRs.
pkaler 15y ago
ARM is basically doing to Intel what Clayton Christensen taught Andy Grove to do with the Celeron. http://hbr.org/2010/07/how-will-you-measure-your-life/ar/1 http://hbr.org/2010/07/how-will-you-measure-your-life/ar/1
- watmough 15y ago
  That's a great story. Thanks for posting it. Actionable material.
renownedmedia 15y ago
Hopefully the next iteration of the Raspberry Pi will have this!
- brigade 15y ago
  It's currently using a 6+ year old ARM11.
  - renownedmedia 15y ago
    Damn... I had no idea. I guess that would explain why my year old cell phone is more powerful. Thanks for the info! Perhaps Version 4 of the Raspberry Pi will use it!

113 points by codedivine 15y ago

Is there any backstory on why this is only happening now? The address space situation is already borderline in some areas of ARM usage, and cell phones are about to break 1GB of physical RAM (if some haven't already?). Seems like this is a couple years overdue to have anything close to a comfortable margin.

mbell 15y ago
The instruction architecture is irrelevant to the issue of address space. The Cortex A15 can already address up to 1TB of memory.
- 0x0 15y ago
  Well, even 32bit x86 can address more than 4GB memory, but at least there you have to use horrible hacks like PAE. When the native data size is smaller than the address space, taking advantage of the full address space and working with large data sets becomes a hassle.
- nknight 15y ago
  No, it can do glorified bank-switching. That's not an increase in address space, it's a hack that assumes applications will still keep their memory usage to no more than 2-3GB.
  - mbell 15y ago
    Its not bank switching, its the MMU mapping the 32bit virtual address space of each process to a much larger physical address space. You are right that each process is still limited to 32 bits of virtual address space but bank switching has nothing to do with it.
    - nknight 15y ago
      Having extra hardware to help speed it up doesn't stop it from being bank switching. That is its essential nature, it doesn't matter how heavy the lipstick is.
    - CountSessine 15y ago
      Having extra hardware to help speed it up doesn't stop it from being bank switching. That is its essential nature, it doesn't matter how heavy the lipstick is. By that same logic, all of paged memory management is bank switching. I might also point out that current x86 CPUs map 64-bit addresses into 43-bit physical addresses using pages. Is that reverse-bank switching? It's purely coincidental if your CPU was designed to map N-bit virtual-space pointers into N-bit physical-space pointers. It's much more common, both now and historically, to map from N-bit to M-bit. There is no hack here.
      - mbell 15y ago
        Its worth mentioning also that x86 64bit CPUs still use PAE, in fact they have to, its mandatory in long mode ("real 64 bit mode"). Additionally the version of PAE used in 64 bit mode is an extension of the original 32 bit PAE, adding an extra directory layer to support up to 52 bits of physical address space. Although i don't think any processor has implemented more than 48bits of address space so far.
- masklinn 15y ago
  Oh? How does it handle this? Something similar to PAE? To PSE? Explicitly using cooperative coprocessors? A completely different scheme? Also, isn't it relevant to process-addressable (virtual) memory? Barring explicit APIs such as AWE. As far as I know, ARM registers are 32b so a process should not be able to load data from an address higher than the 4GB mark (in its virtual memory), am I wrong?
  - mbell 15y ago
    Two separate issues, memory per process (which is limited to 32bits of address space) and total physical address space available to the MMU. It is similar to PAE in fact ARM calls it LPAE.
gecko 15y ago
I'm not entirely sure I agree with you. 1. Cell phones may cross over the 2 GB boundary soon, but ARM can already comfortably address terabytes of RAM through segments, as mbell notes. At worst, we're limiting individual applications to under 2 GB of RAM--not the end of the world. 2. While being able to address 64 bits at once is useful for some computing tasks, *most* of those (scientific computing being a biggie, but also some parts of video editing or sound mixing) just aren't ones people currently do on a cell phone. They likely will eventually, but the hold-up there is as much about getting the data onto the phone in the first place as actually doing anything significant with it. 3. Adding 64-bit wide paths adds a *lot* of silicon for something that would currently not get used at all, and in the future won't get used much for quite some time. More silicon means a shorter battery life and more heat--not exactly what you want in a cell phone. Look at how much effort ARM's going to in big.LITTLE just to let them go superscalar, let alone 64-bit. 4. Finally, the on case where you might get good benefit--games--are better served through GPUs and ARM's existing NEON instructions, which already work on I believe 128-bit-wide values. So those are all the reasons why I don't see the lack of 64-bit ARMs right now as a real problem. And, indeed, if ARM were only getting used in cell phones, I wouldn't honestly see a pressing need to go to 64-bit chips, period. But ARM wants to move into servers, and there, the situation's obviously very different. 64-bits is a no-brainer for any moderately sized database, and that's where I suspect ARM really needs this ISA. But those will take a few years to build and gain acceptance, anyway; they've got time.
- anamax 15y ago
  > Adding 64-bit wide paths adds a lot of silicon for something that would currently not get used at all, and in the future won't get used much for quite some time. I can't find the quote, but John Mashey said that adding 64 bit support to MIPS processors cost something like 5% area. Datapaths and architectural registers really aren't that expensive in area or power. It does takes more power to move 64 bits across the pins and 64 bit addresses take more space. I suspect that those factors are far more important wrt battery and cell phone cost than the processor costs.

ricw 15y ago

My prediction: once this architecture is in the release channels, Intel is out of them. In a matter of years, Intel will be the dinosaur of microprocessors. Unless Intel also (re-)embraces ARM. Its simply a matter of price and configurability. ARM is simply unbeatable when it comes to price. Let alone energy efficiency. Its time to short Intel shares..

luu 15y ago
ARM is unbeatable in terms of price right now, but that's because they have much smaller parts that are much cheaper to produce. What makes you think that will still be true if they want to approach the performance of mainstream Intel parts? Historically, low-end parts have managed to kill high-end parts by selling in larger volumes and amortizing their fixed costs over a larger base. ARM sells in huge volumes, but how is selling $1 embedded chips going to help them amortize the cost of their high end stuff? Decades ago, doing that sort of thing would helped Intel fill up their idle fab time while competitors like DEC struggled to pay for their fabs, but ARM has never owned its own fabs, and selling completely different low-end parts doesn't really help amortize the cost of masks, post-silicon debug, etc. of their high end parts. I'm also skeptical that ARM will retain its power:performance advantage if it tries to scale up performance to match low-end mainstream Intel parts (e.g., core i3). The main reason ARM has better performance:power is that there are diminishing returns to performance. Another is that Atom is a new product line, and Intel doesn't have much experience trying to optimize for low-end parts. That won't be true going forward. Yet another transient advantage ARM has is that Intel uses a high performance process, but they've said that they're going to have both a high performance and a power optimized process in the future. If anything, Intel's process wizardry should give them an advantage there, once they decide to push it. What other inherent advantages does ARM have over x86? It's a PITA to decode x86 instructions, but the ARM instruction set isn't very nice, either (e.g., look at how they ran out of opcode space, and overlayed some of their "new" NEON instructions on top of existing instructions by using unused condition codes for existing opcodes). I wouldn't bet against ARM but, if they win, it will be because of the usual reasons: better marketing, better business practices, and better engineering, not because there's some inherent advantage that lets them be cheaper than Intel. And, by the way, the configurability advantage you mention actually hurts them in terms of cost, by increasing the fixed cost per part.

Symmetry 15y ago

This link has a bit more information. http://www.arm.com/about/newsroom/arm-discloses-technical-details-of-the-next-version-of-the-arm-architecture.php http://www.arm.com/about/newsroom/arm-discloses-technical-de... I wonder how these two new modes will relate to existing modes like Thumb2?

DiabloD3 15y ago
I would not be surprised if they made a Thumb32 to match Thumb. Its a rather useful mode for certain kinds of programming from what I've heard from coders on ARM platforms I know.
brigade 15y ago
Even more information: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf http://www.arm.com/files/downloads/ARMv8_Architecture.pdf The answer is that there is only one 64-bit ISA, but all current 32-bit modes are still supported.
- Symmetry 15y ago
  Yeah, I just found that this morning. I'm sort of leery of the move to 32 GPRs.

pkaler 15y ago

ARM is basically doing to Intel what Clayton Christensen taught Andy Grove to do with the Celeron. http://hbr.org/2010/07/how-will-you-measure-your-life/ar/1 http://hbr.org/2010/07/how-will-you-measure-your-life/ar/1

watmough 15y ago
That's a great story. Thanks for posting it. Actionable material.

renownedmedia 15y ago

Hopefully the next iteration of the Raspberry Pi will have this!

brigade 15y ago
It's currently using a 6+ year old ARM11.
- renownedmedia 15y ago
  Damn... I had no idea. I guess that would explain why my year old cell phone is more powerful. Thanks for the info! Perhaps Version 4 of the Raspberry Pi will use it!