3 ms·

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

by 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.
- uriel 15y ago
  It is such a shame that ARM has taken over MIPS place in the embedded world, and that SGI crashed and killed it in the server space, MIPS is a much nicer architecture than ARM or PPC, (and nevermind SPARK or god forbid IA64).
- ramchip 15y ago
  Your quote is here: http://www.eng.auburn.edu/~agrawvd/COURSE/READING/ARCH/road_to_64bits.pdf http://www.eng.auburn.edu/~agrawvd/COURSE/READING/ARCH/road_... Although not without subtle problems, the hardware was generally straightforward, and not that expensive—the first commercial 64-bit micro’s 64-bit data path added at most 5% to the chip area, and this fraction dropped rapidly in later chips. Most chips used the same general approach of widening 32-bit registers to 64 bits. Software solutions were much more complex, involving arguments about 64/32-bit C, the nature of existing software, competition/cooperation among vendors, official standards, and influential but totally unofficial ad hoc groups. I think it's talking about the MIPS R4000. It's nice to mention registers, but what about the increase in size of the comparators, adders, multipliers/dividers (ouch), cache system, bus interface, decoder, etc.? Perhaps the point is that being 64-bit compatible does not take a lot of surface, even though being fully 64-bit would be expensive. The article mentions how being forward-compatible can be a good thing (even if it costs a little performance), so I suppose it would make sense to support 64-bit right now and make it fast later, without breaking ISA compatibility. Edit: reading about the MIPS R4000, it's definitely not a fully 64-bits processor. Some Wiki quotes: The shifter is a 32-bit barrel shifter. It performs 64-bit shifts in two cycles, stalling the pipeline as a result. This design was chosen to save die area. The multiplier and divider are not pipelined and have significant latencies: multiplies have a 10- or 20-cycle latency for 32-bit or 64-bit integers, respectively; where as divides have a 69- or 133-cycle latency for 32-bit or 64-bit integers, respectively. Most instructions have a single cycle latency. The ALU adder is also used for calculating virtual addresses for loads, stores and branches. The memory management unit (MMU) uses a 48-entry translation lookaside buffer to translate virtual addresses. The R4000 uses a 64-bit virtual address, but only implements 40 of the 64-bits for 1 TB of virtual memory. The remaining bits are checked to ensure that they contain zero. The R4000 uses a 36-bit physical address, thus is able to address 64 GB of physical memory. (By the way, thanks for the quotation, that was quite an interesting read. I didn't expect forward-compatibility to be so cheap.)

by gecko 15y ago

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.

uriel 15y ago
It is such a shame that ARM has taken over MIPS place in the embedded world, and that SGI crashed and killed it in the server space, MIPS is a much nicer architecture than ARM or PPC, (and nevermind SPARK or god forbid IA64).
ramchip 15y ago
Your quote is here: http://www.eng.auburn.edu/~agrawvd/COURSE/READING/ARCH/road_to_64bits.pdf http://www.eng.auburn.edu/~agrawvd/COURSE/READING/ARCH/road_... Although not without subtle problems, the hardware was generally straightforward, and not that expensive—the first commercial 64-bit micro’s 64-bit data path added at most 5% to the chip area, and this fraction dropped rapidly in later chips. Most chips used the same general approach of widening 32-bit registers to 64 bits. Software solutions were much more complex, involving arguments about 64/32-bit C, the nature of existing software, competition/cooperation among vendors, official standards, and influential but totally unofficial ad hoc groups. I think it's talking about the MIPS R4000. It's nice to mention registers, but what about the increase in size of the comparators, adders, multipliers/dividers (ouch), cache system, bus interface, decoder, etc.? Perhaps the point is that being 64-bit compatible does not take a lot of surface, even though being fully 64-bit would be expensive. The article mentions how being forward-compatible can be a good thing (even if it costs a little performance), so I suppose it would make sense to support 64-bit right now and make it fast later, without breaking ISA compatibility. Edit: reading about the MIPS R4000, it's definitely not a fully 64-bits processor. Some Wiki quotes: The shifter is a 32-bit barrel shifter. It performs 64-bit shifts in two cycles, stalling the pipeline as a result. This design was chosen to save die area. The multiplier and divider are not pipelined and have significant latencies: multiplies have a 10- or 20-cycle latency for 32-bit or 64-bit integers, respectively; where as divides have a 69- or 133-cycle latency for 32-bit or 64-bit integers, respectively. Most instructions have a single cycle latency. The ALU adder is also used for calculating virtual addresses for loads, stores and branches. The memory management unit (MMU) uses a 48-entry translation lookaside buffer to translate virtual addresses. The R4000 uses a 64-bit virtual address, but only implements 40 of the 64-bits for 1 TB of virtual memory. The remaining bits are checked to ensure that they contain zero. The R4000 uses a 36-bit physical address, thus is able to address 64 GB of physical memory. (By the way, thanks for the quotation, that was quite an interesting read. I didn't expect forward-compatibility to be so cheap.)