Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Hardware

ARM Goes 64-Bit With Its New ARMv8 Chip Architecture 156

angry tapir writes "In less than a decade, a microprocessor core could be no bigger than a red blood cell, the CTO of ARM has predicted. ARM has already helped develop a prototype, implantable device for monitoring eye-pressure in glaucoma patients that measures just 1 cubic millimeter, CTO Mike Muller said at ARM's TechCon conference. At the conference the company also introduced its first 64-bit chip. The ARMv8 adds 64-bit addressing capabilities, an improvement over the current ARMv7-A architecture, which is capable of up to 40-bit addressing. The architecture puts ARM into more direct competition with Intel and its 64-bit Xeon processors."
This discussion has been archived. No new comments can be posted.

ARM Goes 64-Bit With Its New ARMv8 Chip Architecture

Comments Filter:
  • Architecture (Score:5, Informative)

    by ice3 ( 1305003 ) on Friday October 28, 2011 @07:18AM (#37867178)

    Here's a better description of the new Architecture:

    ARMv8 Architecture PDF [arm.com]

    • Thanks. A few interesting things:

      Full double-precision support in the vector unit is big win. Current ARM chips suck when you have to do anything with double precision floating point values.

      No Thumb-3, so you're stuck with 32-bit instructions in 64-bit mode, which don't give as good i-cache usage. That's a shame, but I guess you can always run 32-bit Thumb-2 apps on your 64-bit kernel. There's no blx to 32-bit mode, you're stuck in 64-bit mode for an entire process (which makes sense).

      Weakly ordered

      • They also seem to have doubled the number of registers to 32 (+32 SIMD registers) in the 64-bit mode, like AMD did with x86-64. I don't know if it'll provide much performance increase though since they already had a decent amount, unlike x86.

        • I suspect the improvements to the SIMD registers are going to make more of a difference. 16 integer registers is usually enough to avoid needing to spill to the stack. It really depends on how they're split between callee- and caller-save, but that's a decision for the ABI, rather than the ISA. A few more argument registers would probably help Objective-C, where you have two used for self and _cmd, so arguments are more likely to spill to the stack. A few more caller-save registers could reduce the numb

  • BS (Score:4, Insightful)

    by Anonymous Coward on Friday October 28, 2011 @07:21AM (#37867202)

    > "The architecture puts ARM into more direct competition with Intel and its 64-bit Xeon processors."

    Who is writing and editing this BS? It is not in any way putting ARM in competition with Xeon CPUs. It is becoming a serious contender for low end CPUs: Atom, Pentium, Athlon, and it is getting more interesting for streaming and massive threading applications (like the SPARC T).

    • Re: (Score:2, Funny)

      by Anonymous Coward

      In other news, Toyota is now offering the Prius in a two door variant. This design puts the Prius into more direct competition with Ferrari and it's two door sports cars.

    • by Surt ( 22457 )

      Nvidia project denver.

    • Who is writing

      Well, if you look at submitter's name link you'll see "http://www.techworld.com.au/", which just happens to be where the summary links to.

      and editing this BS?

      Why that would be one of the crack Slashdot "editing" staff, who are more than happy to link to subby's techrag clickbait (probably collecting a fee for Geek.net).

    • And if ARM is currently 40-bit, that means their address space limit is 1 TB - which is plenty for all but really high end servers anyway. The difference between 40 bit and 64 bit is probably not relevant for most consumer and server applications anyway, especially since port from x86_64 to ARM is a lot of work regardless of whether ARM is 40 or 64 bit.

      I'm hoping ARM chips are performance-competitive with x86_64 chips within a decade just because AMD is having problems, and giving Intel an effective m
      • I won't argue that 40 isn't a lot of bits. But frequently bits are used for different purposes than part of addressing memory locations. Especially in the microcontroller world.

        • by vadim_t ( 324782 )

          ARM isn't a microcontroller. A microcontroller is something with 1K RAM and 16K flash, and a set of pins useful for talking to external devices, like a serial port, digital outputs with PWM and integrated AD converters.

          ARM is a low power CPU and if they're smart they'll do like x86 and require the unused bits to be all set to 1 or 0 so that they can't be repurposed.

          • by tlhIngan ( 30335 )

            ARM isn't a microcontroller. A microcontroller is something with 1K RAM and 16K flash, and a set of pins useful for talking to external devices, like a serial port, digital outputs with PWM and integrated AD converters.

            ARM is a low power CPU and if they're smart they'll do like x86 and require the unused bits to be all set to 1 or 0 so that they can't be repurposed.

            Depends on the project. There are ARM-based microcontrollers out there with 128k flash and maybe 256k of RAM. And with onchip peripherals, havi

    • Core-to-core performance? Obviously, Xeon beats ARM lower than dirt. Watt-to-watt performance? Xeon gets thrashed.

    • by LoRdTAW ( 99712 )

      Think of it like this, ARM is small and lean on power. You could pack dozens of cores onto a die giving it the power to compete with the Xeon. Blade servers can be shrunk down and more can fit into a single U of rack space since ARM does not dissipate tens of watts. We might see something along the lines of servers that are nothing more than a mini cluster in a box that appear as one whole system. A prepackaged beowulf cluster if you will.

      There was an interesting video I saw a while back of a researcher who

  • Really needed? (Score:2, Informative)

    by Anonymous Coward

    Is 64-bit really needed in mobile devices? It increases the number of wires and data transfer, which means less power efficiency.

    • by Surt ( 22457 )

      Mobile devices will soon need to pass the 4gb/process barrier, so yes, it's needed.

      • "I got me 64 gigabytes of RAM;
        I don't feed trolls and I don't ream SPAM;"

        -- Weird Al
        Hmm, will have to change the refrain, it's not all about the Pentiums anymore, baby.

      • by afidel ( 530433 )
        You have an interesting definition of soon since no mobile device yet produced even has 4GB of ram. Heck it was this year when the 1GB barrier was broken. I would guess in 3 years we'll have a 4GB phone, but it will be a while before 4GB/process is any kind of barrier, it's not like you'll be running a RDBMS on your phone.
        • Re:Really needed? (Score:5, Insightful)

          by Surt ( 22457 ) on Friday October 28, 2011 @08:34AM (#37867846) Homepage Journal

          I'd expect it within 5 years, which seems to be the rough time-frame in which ARM expects the first of these CPUs to be built. This is just the architecture announcement. They need to get it out there so people can begin building tools, etc. There's barely enough time to get all that work done in time before this becomes a serious handicap for ARM, so that's my definition of soon.
           

        • I run MySQL in a chroot on my Xoom you insensitive clod!
          • You would be better off with PostgreSQL.... ;)

            Seriously though, I would probably use SQLite or FirebirdSQL Embedded if I were to use a database on that tight of a hardware spec. I've been somewhat eagerly watching Raspberry Pi to see where that leads.
        • These chips need a bunch of address space to access peripherals. When you are at 2GB it starts to get a little tight, depending on how big the windows are for your I/O space (64M per peripheral is not an uncommon size, even if it is just for the registers for a serial or I2C port). Once you get 4GB then you really are stuck and have to use extended addressing and play highmem games in the kernel.

          • Serial/I2C ports need like, 16 addresses at the most. Are they really that wasteful?
            • yes, that has been my experience :(
              When you do address decoding off a bus you can break a large range into equal sizes power-of-two blocks pretty easily, and have a very gate-conservative circuit to turn those bits in the middle of your address into enables for the peripherals on the internal bus. I would rather they slice it up into smaller pages and just give some of the more complicated parts multiple pages (tie the enable lines together with an OR). But I'm just a software guy, I might be over simplifyi

        • by smash ( 1351 )
          My laptop has 8gb of ram today. If ARM can increase outright performance a bit (perhaps through using many many cores and the use of threading on processing intensive apps) then I'd be keen on ARM for the power savings.
      • From the article, current ARM processors have a 40 bit architecture, which puts the process barrier at 1TB. Every mobile device produced in the next 20 years is probably not going to hit that ceiling.
        • by Surt ( 22457 )

          The registers are 32 bit, though, which means paged addressing. No one wants to write apps in that environment.

    • by Tsingi ( 870990 )

      Is 64-bit really needed in mobile devices? It increases the number of wires and data transfer, which means less power efficiency.

      Hey no one will ever need more than 2^64 bytes of RAM!!!

    • I guess that would depend on what you mean by "needed". It's never going to be needed in the sense that there is nothing about storing some phone numbers and reading some email that needs fast double precision floating point numbers or 5 gigs of ram. In that sense, it's not even REALLY needed on the general desktop yet.

      I'm going to guess that some day, mobile devices will have 16 gigs of ram. Battery tech will have advanced enough to let such a device run for 8 hours. So yes 64 bit will be needed because
      • by Surt ( 22457 )

        Mobile devices are going to be the most common platform for games soon, including 3d games, and there you can definitely use more than 4GB for a process.

        • by Tr3vin ( 1220548 )
          Let me know when my PC games are going to come even close to using 4GB of ram. I'm always disappointed in the lack of memory use on my gaming rig. Most modern games rarely hit 1GB of mem usage from what I have seen. Rage didn't even bother caching it's many large textures in memory.
          • by Surt ( 22457 )

            Probably Christmas 2013. 2014 at the latest. By then no 'gamer' system sold in the previous 2 years will have had less than 8gb ram.

            • As someone who hasn't had a system in 5 years with less than 8GB of ram, that would be a good thing... especially since I've been thinking of upping to 16GB since it's really (tm) cheap right now.
          • by TheLink ( 130905 )
            Run 4 flash games in firefox/chrome, leave them overnight and each might take 1GB ;).
          • by Bengie ( 1121981 )

            I've have a few games that break 3GB regularly, but they are tweaked for low memory usage, so they have smaller textures/etc, but they have lots of objects. If they ever went with high res textures and high poly count models, 64bit may be needed.

        • by Toonol ( 1057698 )
          Mobile devices are going to be the most common platform for games soon, including 3d games, and there you can definitely use more than 4GB for a process.

          I don't think so. Games of any moderate graphical complexity burn too much energy, and battery technology is advancing too slowly. For phones to take share in the gaming field away from consoles or PCs, they would need better ergonomics (connectable controllers), better power (probably plugging into an outlet while playing), and output to the TV.

          In
          • by Surt ( 22457 )

            I was including Nintendo/Sony handhelds. They surely aren't going to eliminate the other market, just be more common. I'm just predicting that handheld gaming will be 51% or more of gaming. It may already be true, but it surely will be true soon if not.

    • by smash ( 1351 )
      If you count laptops in that, then sure.
    • Mobile? Well, my current laptop is using 64-bit processes and none of them has even 1GB of address space mapped, so it will be a little while. That said, ARM won't release any core designs with this ISA until at least next year, and they probably won't make it into shipping products for another year.

      Mobile isn't the only place ARM is aiming though. Low-power servers are a growing market and the 40-bit LPAE in the A15 is likely to look a little bit cramped in the next few years. Servers often want to

    • The MB per Angry Bird requirement is ever increasing. The much anticipated neural net selection & genetic pruning algorithms will see to that.
  • by dabadab ( 126782 ) on Friday October 28, 2011 @07:24AM (#37867232)

    It is worth pointing out that current x86-64 implementations are limited to addressing "only" 48 bits [wikipedia.org] so it's not like that ARM was way beyond the curve with their 40 bit address space (that's 1 TB).

    • 2^40 / 1024 / 1024 / 1024 / 1024 = 1 TB of addressable memory. I concur that is enough for modern data centers machines that generally contain 2 CPU's with 8 physical cores loaded up with 96 GB of RAM.
  • The summary and article both imply that 64 bit addressing means a 64 bit processor. That's not the case. The ARMv8 is a 64 bit processor because it adds 64 bit processing support:

    The ARMv8 architecture consists of two main execution states, AArch64 and AArch32. The AArch64 execution state introduces a new instruction set, A64 for 64-bit processing. The AArch32 state supports the existing ARM instruction set.

    - ARM press release [arm.com]

    • by Surt ( 22457 )

      It also supports 64 bit addressing. So by whichever definition you prefer, it's a 64-bit processor. Unless of course you demand full 64 bit address space as your bar for true 64-bitness, in which case no one sells such a processor yet.

  • Not just Intel (Score:5, Informative)

    by imroy ( 755 ) <imroykun@gmail.com> on Friday October 28, 2011 @07:30AM (#37867278) Homepage Journal

    The architecture puts ARM into more direct competition with Intel and its 64-bit Xeon processors.

    Gee, what about AMD and the AMD64 architecture that they developed? You know, the one that Intel eventually had to adopt (license?) when their 64-bit Itanium didn't quite live up to their expectations of being the next architecture that everyone moved to?

    Oh, and ARM Holdings don't make chips. They design architectures and implementations that others license and put into actual chips. The summary wasn't so clear on that, and it's a point that lots of people often overlook.

    • by smash ( 1351 )
      You talking about the same AMD that hasn't released a CPU worth shit in about 4 years now?
      • by gknoy ( 899301 )

        Benchmarks of their chips often seem to put them at rough parity with intel, when you look at price vs performance.

  • by necro81 ( 917438 ) on Friday October 28, 2011 @07:34AM (#37867314) Journal

    The architecture puts ARM into more direct competition with Intel and its 64-bit Xeon processors

    Maybe I've just got a certain prejudice, but I don't see any direct comparison, let alone competition, between ARM processors and Xeon processors, no matter how wide their addressing is. ARM processors run some really sophistocated stuff ... in my smartphone. A Xeon processor allows my CAD workstation to handle 3D models with thousands of components, or run an ANSYS simulation that solves the equivalent of 10 million simultaneous equations.

    • by JanneM ( 7445 )

      Not for workstations, I agree (I have one as well at work). But once you start piling up CPUs in racks by the hundreds the raw power matters less than the power per watt. Power and heat dissipation becomes the limiting factor in how much processing power you can cram into a given facility, or the total size, construction and installation cost for a bespoke facility. And while the Xeon is fast it and its support circuitry is rather a power hog.

      • These are my feeling as well. I think that having a couple thousand compute units with say 40-60GB of SSD storage and even 1-2GB of RAM would go a long way in a cluster, or sharded data store.
    • by Bert64 ( 520050 )

      The same was said about x86 when comparing it to the highend alpha/mips/sparc/ppc of the time.

      Never underestimate competition coming from below...

    • Competition to the Xeon line isn't going to happen in the workstation; it's going to happen in the data center. As we stand now, the major limiting factor in terms of how much performance you can squeeze into an data center is the ability to power and cool your cores, rather than the number of processors and associated infrastructure that you can physically squeeze into a given space. This has more or less been the limitation since the introduction of the U1 form factor, and has been getting even worse with

  • by Prune ( 557140 ) on Friday October 28, 2011 @01:13PM (#37871646)
    ARM still has a serious weakness versus x86 and x86-64: it uses a weak memory consistency model. For single-threaded applications that's no issue, but the overwhelming majority of programmers cannot effectively utilize the potential compute power in a multicore environment. In x86-64 it's quite easy because there's very limited reordering (with the exception of some SSE operations) and it is possible to reason about it efficiently after some experience. Sure, you can rely on locking for 100% of your synchronization, but you'll kill performance.
    • by rdnetto ( 955205 )

      ARM has an even more fundamental problem then that in it's current implementation. There's effectively no equivalent of 'IBM compatible' right now. If you look at the different devices which are using Tegra 2 chips (not just the same family, but the same actual chips), they're all using different GPIO pins. The end result is that we're using customized kernels for each device, which is obviously impractical. There's also no standardized way to load a bootloader - everyone's just using closed source bootload

Never test for an error condition you don't know how to handle. -- Steinbach

Working...