8 ms·

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 abou

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

by nknight 15y ago

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.