ARM Goes 64-Bit With Its New ARMv8 Chip Architecture

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

Comments

Architecture

[ice3]

Here's a better description of the new Architecture:

ARMv8 Architecture PDF

Re:Architecture

[oakgrove]

FWIW, I have a Motorola Xoom with a Tegra2 clocked at 1.4 GHz with Ubuntu running in a chroot. I also have an Acer Aspire One with an N270 processor at 1.6 GHz. On every commandline benchmark I've done, the Xoom edges it out. My understanding is that anything involving an FPU, the Atom would come out on top but in my experience, the Xoom is very much on par with the Aspire in day to day use.

Re:Architecture

[KiloByte]

New ARMs do have a FPU. Efficiently making use of it, though, requires an ABI change. Ubuntu still uses armel rather than armhf. It's not yet in the official Debian archive yet, too -- but you can already try the candidate in a chroot. Not surprisingly, floating point benchmarks get a massive improvement.

Re:Architecture

[TheRaven64]

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 following the C1x / C++11 memory model: that's going to break a lot of code that was written for x86 and assumes a strongly-ordered architecture. It also means that, for good performance, people are going to have to actually read the documentation for stdatomic.h / , which is something no one wants to do.

Crypto instructions... meh. If you've got an application doing a lot of crypto, you're probably using these via an on-die coprocessor anyway. Also, hard-coding the crypto algorithms into the ISA seems like a mistake.

No shipping silicon until 2014 from ARM, although rumour has it that nVidia has an A64 core design almost finished and ready to appear in a Tegra chip in 2012.

Re:Architecture

[TheRaven64]

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 number of register-register moves in a few complex sequences, but probably not very many for C-family code.

Languages like Lisp and Haskell are more likely to benefit. SBCL, for example, really likes having at least 16 registers to play with and 32 generally results in better code.

BS

[Anonymous Coward]

> "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:BS

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

Really needed?

[Anonymous Coward]

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

Re:Really needed?

[Tsingi]

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

Re:Really needed?

[Surt]

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.

Re:Really needed?

[Surt]

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.
 

Re:Really needed?

[Surt]

But with 32 bit registers, that's paged. No one wants to write paged applications.

Actual implementations

[dabadab]

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

Not just Intel

[imroy]

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.

Re:Not just Intel

[smash]

You talking about the same AMD that hasn't released a CPU worth shit in about 4 years now?

Direct Competition?

[necro81]

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.

Re:Direct Competition?

[Bert64]

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

Re:Direct Competition?

[Misagon]

Your statement that ARM should be based on Motorola 68000 is incorrect. The ISAs of the two architectures is completely different. ARM has 32-bit instructions, for instance, while the 68000 has 16-bit instructions. ARM processes the entire 32-bit word, while the 68000 processes 8, 16 or 32-bit words. etc.

Were you confused by the Dragonball series of microcontrollers, that was used in the PalmPilot? Early versions had a 68000 core and later versions had an ARM core.

Re:Direct Competition?

[Alioth]

ARM is *NOT* based on the 68000 design, it was an original CPU design by Acorn computers of Cambridge, England (ARM originally stood for Acorn Risc Machine) for their desktop computers in the late 1980s and during the 90s. ARM bears absolutely no resemblance to 68000.

Sophie Wilson and Steve Furber, the designers of the ARM, were inspired by the simple architecture of the 6502, but the ARM is not based on that either (the ARM does not resemble the 6502 either, nor is it based on the 6502).

Re:Direct Competition?

[robthebloke]

Read the technical docs on arm. It continually states that the new architecture was designed specifically to address needs within their current market sectors (eg mobile devices). Nowhere does it make any reference to high density servers, let alone desktops. The article uses a single quote that 'ARM' said it will enable it to take on the server market, and yet it does not cite the individual who has said that. If the article said "Joe Bloggs, senior tech foo-whatever-job @ ARM said...", then I might be inclined to believe it. As it is, it just looks like lazy journalism.

Standardized boot process

[tepples]

At least "god damn x86" has a standardized boot process, be it BIOS or EFI. Let me know when more than one make and model of ARM computer can boot from the same memory card.

Re:64-bit CPU or 64-bit adresssing?

[peppepz]

Well, there is no "real" definition of a "n-bit CPU".

Anyway, ARMv8 has 64-bit registers, a 64-bit logical address space, a 48-bit physical address space, and 32-bit wide instructions.

4GB is all it takes to break the barrier

[OrangeTide]

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.

ARM multicore problems

[Prune]

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.