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

fucking finally

[Anonymous Coward]

god damn x86.

Architecture

[ice3]

Here's a better description of the new Architecture:

ARMv8 Architecture PDF

Re:Architecture

[muon-catalyzed]

Has anybody benchmarked ARM vs Intel already? I mean in some standard test like SuperPI? How do these cores compare speed/Watt?

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

[DarkOx]

A Marvel kirkwood core @1.2Ghz, is about half as many bogomips as an intel Atom N280

Re:Architecture

[DarkOx]

Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1192.75
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Marvell GuruPlug Reference Board

Re:Architecture

[daid303]

You are comparing bogomips of an ARM vs X86? Now that's the stupidest 'benchmark' you could EVER do.
http://en.wikipedia.org/wiki/BogoMips
"It is not usable for performance comparison between different CPUs."

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

[Narishma]

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.

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.

Re:BS

[Surt]

Nvidia project denver.

Re:BS

[Megaweapon]

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

Re:BS

[DuckDodgers]

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 monopoly on high end processors will probably lead to unnecessarily high prices.

Re:BS

[KiloByte]

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

Re:BS

[Talennor]

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.

Re:BS

[vadim_t]

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.

Re:BS

[LoRdTAW]

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 packed 196 of those ARM gumstix modules into a case not much bigger than a tower PC with no forced cooling. I cant find the video but here is a link to information about the cluster:

http://www.linuxfordevices.com/c/a/News/Sandia-StrongBox-and-Gumstix-Stagecoach/

Re:BS

[Anonymous Coward]

The virtual addressing is 64-bit (hence the 64-bit architecture naming). The physical address is currently 40-bit but there are spare bits in the page table entry to allow this to grow well beyond.

Re:BS

[LoRdTAW]

Whoops, it is forced air cooled and built by Sandia National Labs: http://www.youtube.com/watch?v=UPyn9krjIRc

Still it does demonstrate that you can really tightly pack ARM systems into a box to raise computing power.

Re:BS

[tlhIngan]

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, having ADCs, DACs, timers, and other stuff is quite trivial, as well as requisite GPIO.

ARM scales everywhere - it's probably one of the most widely shipped architectures out there - your PC alone may have several ARM cores in it (for WiFi, Bluetooth, maybe the optical drive). Your smartphone and tablet may have several as well - besides the main processor, there's probably one (or two!) driving the 3G, Bluetooth, WiFi and the like.

The deal is, not all ARMs have to be the latest and greatest - there's still ARM9 processors used in lightweight applications (v5), ARM11s (v6), and Cortex A (applications), and M (microcontroller) series (v7).

Re:BS

[unixisc]

Does the 40-bit address limit then make the ARM a 40-bit CPU? I thought that the definition of a 64-bit CPU was one that can do arithmetic & logical operations on 64-bit wide data. Very few 64-bit CPUs use, or ever used 64-bit addresses. DEC Alpha used I recall 43, Intel Itanium uses 48, and nobody went all the way up to 64. Only reason I can think for doing this is if they are using a multiplexed address/data bus.

As for monopolies, don't worry - IBM still has Power7, Oracle still offers UltraSparc, and if Intel tries to jack up prices, watch these two start stealing marketshare.

Re:BS

[ckaminski]

The Instruction set architecture (ISA) tells how much memory can be addressed as a pointer (like C++). In the 32bit ISA that's 4GB. In a 64bit ISA that's a shitload more.

Intel CPUs for a long time could actually address 36bits of memory, the so-called Page Address Extensions (PAE mode) - exposed in Windows Server, for example. But programs on those CPUs could only access 4GB at a time continguously.

Basically it's the size of the largest array you could allocate and walk with pointer arithmetic, ie: *(i++)

Keep going

[Anonymous Coward]

128bit and 256bit next, as long as it's 32bit backward compatible, why stop?

(Not for the RAM size's sake, but for performance)
Transmeta did something similar, so why not.

Re:Keep going

[Oswald McWeany]

Why both going through 128 and 256 bit?

Just make the leap up to 1024 bit! It's inevitable eventually...

Re:Keep going

[petermgreen]

Note that register size and address size need not be the same. There were many processors out there with 16-bit memory addresses but only 8-bit registers and data bus. Likewise most 16-bit systems had some mechanism for accessing more than 2^16 memory addresses. Even 32-bit systems often had mechanisms for accessing more than 2^32 memory address though they were little used.

OTOH 64-bit CPUs often don't bother with support for full 64-bit addresses (though they are often designed so they can be allowed in future without changing userland code) because people simply don't have anywhere near that much memory.

I don't think there is much point increasing the size of integer data words beyond 64-bit. Most apps simply don't need numbers that big.

Re:Keep going

[Pence128]

Most apps have integers that need less than 8 bits. I don't think registers need to be 128 bits, but a wider data bus would be great if you could load/store 2 or 4 registers at a time. I always thought that the larger registers get the more bits are wasted when you only need small numbers. If you could store say 2 x 16 and a 32 in one register and operate on them individually, It would save a lot of room. Can any modern architectures do this or is it not worth it?

Re:Keep going

[Anonymous Coward]

If you could store say 2 x 16 and a 32 in one register and operate on them individually, It would save a lot of room. Can any modern architectures do this or is it not worth it?

A lot of floating-point units and vector units do this. I don't know of any integer units that do. As an example, take a look at how registers are used by SSE instructions.

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?

[Surt]

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

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?

[shadowrat]

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 we aren't going to stop at good enough. You will still just look up contacts, listen to music, and play angry birds, but you WILL do it in 64 bit. That day is probably going to get here sooner than we think.

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?

[afidel]

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?

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

[peppepz]

It will make writing software for them much easier when their amount of RAM + video RAM will approach the 4 GB limit. Which is probably going to happen soon.

Re:Really needed?

[oakgrove]

I run MySQL in a chroot on my Xoom you insensitive clod!

Re:Really needed?

[Anonymous Coward]

According to the summery, ARM chips could already address 40 bits of address space, which is already way more than 4GBs.

Re:Really needed?

[Surt]

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

Re:Really needed?

[Anonymous Coward]

This. The trend is for mobile devices to replace desktops for most uses, connecting to peripherals such as keyboards and monitors as needed. But your primary computer won't be some beige box under your desk, it will be the phone in your shirt pocket. As such, it will take over the tasks people do with today's desktops, and that requires a larger address space.

Re:Really needed?

[DuckDodgers]

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.

Re:Really needed?

[Anonymous Coward]

It's more of a cart before the horse in this case.

Re:Really needed?

[Surt]

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

Re:Really needed?

[Tr3vin]

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.

Re:Really needed?

[Surt]

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.

Re:Really needed?

[Anonymous Coward]

I believe there are already problems in some ARM based devices where there is an exhaustion in virtual address space, not just for applications but in kernel space for devices too. More bits would be welcome here!

Re:Really needed?

[aztracker1]

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.

Re:Really needed?

[aztracker1]

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.

Re:Really needed?

[squizzar]

But are the address registers limited to 32 bits? It's sizeof(void*) that you need, not sizeof(int). Also I'm not sure what you mean by 'paged' applications? Paging is an OS/MMU function - nothing to do really with the address space of the CPU. If you mean the addressable space from a specific process you might be onto something, but again a lot of that is an OS limitation, not a CPU one. You can access 36bits of memory on 32-bit x86 from a single process if you do the right magic for example.

Re:Really needed?

[Toonol]

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 other words, mobile devices will surely come to dominate mobile gaming, but will not make significant headway against 'immobile' gaming, any more than being able to watch movies on your smartphone reduces the demand for home theaters. They're expanding the market, not taking away from the existing players. They might be stealing from Nintendo and Sony's handheld sales...

Re:Really needed?

[TheLink]

Run 4 flash games in firefox/chrome, leave them overnight and each might take 1GB ;).

Re:Really needed?

[smash]

If you count laptops in that, then sure.

Re:Really needed?

[smash]

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.

Re:Really needed?

[smash]

the right magic being paging, or segmenting of memory, which is a more commonly used (recent) term.

Re:Really needed?

[Surt]

Yeah, it's that magic I'm talking about. That's absolutely horrific to program with.
And if you cant mix your void * with your ints, that's also horrible to program with.

Re:Really needed?

[Surt]

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.

Re:Really needed?

[afidel]

Several of the apps on my Android phone use SQLite =)

Re:Really needed?

[Anonymous Coward]

How much RAM does your faggotry take up? I'd bet it's a lot more than 8 gigs.

Re:Really needed?

[TheRaven64]

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 do things like mmap huge files, so a 32-bit userspace address space can be problematic.

Re:Really needed?

[Anomalyst]

The MB per Angry Bird requirement is ever increasing. The much anticipated neural net selection & genetic pruning algorithms will see to that.

Re:Really needed?

[TimothyDavis]

I have been very happy with 16GB, as it has allowed me to turn paging off. Combined with an SSD drive, the machine is very snappy - I rarely have to wait for anything...

Re:Really needed?

[Bengie]

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.

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

Re:Actual implementations

[Anonymous Coward]

it seems armv8 is 48bit too in that regard..

Re:Actual implementations

[Anonymous Coward]

No, this is referring to virtual addressing. 40 bits / 48 bits is physical addressing.

Running 40 bit PA with a 32 bit VA is pretty much impossible (with any sort of performance) for any kind of general purpose system. Redhat, IBM and others spent quite a bit of effort making Linux work with their "PAE", and it pretty much fell over after about (34-5 bits). For some special purposes (like hypervisor, or another application that requires many large-memory user processes with little in the way of kernel caching), then it could be OK. But really, 64 bit VA is required for today's server.

Re:Actual implementations

[Anonymous Coward]

Traditionally, a 64-bit processor is a processor that was a register width of 64 bits, not an address width of 64 bits.

Re:Actual implementations

[Anonymous Coward]

How did this get modded up? The poster doesn't understand the difference between physical and virtual address space. Didn't this use to be a site for people who understood "information technology"?

Re:Actual implementations

[rabun_bike]

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.

Re:Actual implementations

[Anonymous Coward]

According to the slides, ARMv8 also only supports 48 bits of VA per TTBR, and 48 bits of PA.

Re:Actual implementations

[afidel]

Huh? I've run plenty of 32-64GB PAE systems, the only reason they weren't bigger was affordable ram modules and the number of slots available on then current generation hardware didn't allow for bigger and by the time the hardware progressed the software was fully caught up and using the much more sensible (for that sized workload) 64bit OS's.

Re:Actual implementations

[Anonymous Coward]

So in other words, 2^40 / 2^40 = 1 ?

Re:Actual implementations

[rabun_bike]

2^40/2^40 equals 1 here and on the other side of the universe. That doesn't really tell you much though does it (unless you already knew 2^40 was equal to 1 TB of of data)?

2^40 = 1099511627776 bits

1099511627776 / 1024 = 1073741824 KB

1073741824 KB / 1024 = 1048576 MB

1048576 MB / 1024 = 1024 GB

1024 GB / 1024 = 1 TB

Author seems confused...

[msauve]

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

Re:Author seems confused...

[Surt]

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.

Re:Author seems confused...

[Anonymous Coward]

Wrong, 64 bit Power has always had a 64 bit virtual address space, but not 64 bit physical, i.e, address lines (can't remember how many address lines the Power7 has, but it allows several TB of RAM). The mechanism is a bit strange, but it works.

Under Linux for example, he 64 bit kernel is loaded at 12EB (0xC000_0000_0000_0000), that's 3 quarters of the maximum address and modules are 1 EB higher (0xD000_0000_0000_0000). I can't remember what the maximum virtual address space for 64 bit applications, since I compile everything for 32 bit mode. As far as I know, no other architecture allows this, and even the new ARM is limited to 56 bit virtual address space.

Re:Author seems confused...

[Surt]

When I said no one offered such a processor, I think I pretty obviously meant the physical address limitations.

Re:Author seems confused...

[Ant P.]

IBM probably does, if they haven't already phased them out in favour of the pure-128-bit-addressing versions.

Re:A CPU embedded in my genitals? Yes, please!

[baka_toroi]

But you could mine them faster with a GPU on your balls!

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?

Re:Not just Intel

[gknoy]

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

Re:Not just Intel

[the linux geek]

Until Intel made their CPU's (2500k, for example) cheap, and Bulldozer turned out to be garbage.

Re:Not just Intel

[Anonymous Coward]

How do they do that without making chips?

Re:Not just Intel

[unixisc]

Several ways. They can just write the specifications, and the MRDs/Datasheets, which a licensee then implements by having their engineers make the netlists and everything else that's needed to be submitted to their fabs. Another option - they write everything upto the HDL code, but don't submit anything to any fabs - just license it out, and the licensees are then responsible for ensuring that it works with the fabs, and then own the product post tape-out, fab-out and assembly. In short, ARM Holding can do a lot of things without ever selling a single chip - they don't even have to be a fabless semiconductor company.

Re:Not just Intel

[smash]

OK so where's the CPU at parity with a high end mobile core i7?

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?

[Anonymous Coward]

And since this article is directly reflecting a chip designed for low-power high-density servers, your point is not only moot, but shows your lack of reading comprehension.

Re:Direct Competition?

[jedidiah]

I usually compare ARM processors to PC CPUs from the late 90s and early oughts, but I think you attempt to conflate them with the MC68x00 is even funnier.

Re:Direct Competition?

[JanneM]

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.

Re:Direct Competition?

[JanneM]

AFIAK, they're not. It is rather a spiritual (as in inspired by) successor to the 6502 cpu.

Re:Direct Competition?

[Anonymous Coward]

So they compete with the Atom mega-processing racks Intel's been pushing, but not with Xeon.

Re:Direct Competition?

[Anonymous Coward]

AFAIK ARM has nothing to do with the Motorola 68k Processors.
ARM is RISC and the 68k is CISC, they Developed ARM after looking for a succesor to the MOS 6502 and designed their own architecture inspired by the Berkley RISC project.

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?

[Surt]

Nvidia project denver:

http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09&version=live&releasejsp=release_157&xhtml=true&prid=705184

Re:Direct Competition?

[JanneM]

"So they compete with the Atom mega-processing racks Intel's been pushing, but not with Xeon."

Well, no. That's the purview of the current ARM7 architecture (or rather, Atom is designed to compete with ARM7, not the other way around). This seems aimed at a much higher point on the power/performance envelope.

Re:Direct Competition?

[Arlet]

Low-wattage high-performance processors are actually critical for the server environments that Xeon currently dominates

I wonder which one is lower power, the ARM or the Xeon.

Of course, you'd have to measure the power for the entire server board, not just the CPU, and you'd have to measure the power based on the same workload.

Re:Direct Competition?

[robthebloke]

An atom-processing rack is pretty much stillborn in any industry that requires double precision computations - it's just far too slow. It would appear (according to the ARM docs on the architecture) that they have been working on vectorised double precision support. Assuming that the speeds aren't as bad as the ATOM (i.e. a few cycles per instruction, rather than a few hundred), I'd be expecting an ARM rack to be a much more marketable concept than an Atom version.

Arm still has quite a long way to go until it can compete with xeon, but then again, the GPU has shown us that gaffa taping a few hundred simple cores together can produce a computational monster. However, something tells me they probably aren't that interested in that market. They're most likely just trying to safeguard their position in the mobile market with a low cost, quad core 64bit CPU. I somehow suspect that any concept of ARM 'taking on' the xeon is nothing more than slashdot rhetoric.

Re:Direct Competition?

[robthebloke]

He was just confusing the 68k with the 6502. Probably.

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.

Re:Direct Competition?

[MemoryDragon]

Actually you are wrong, the ARM has nothing to do with the Motorola 68K it was a development on its own
specifically designed for the Acorn Risc Computers. After Acorn went down ARM went independend and tried
to survive by the nieches Intel left over. The nieches now have become mainstream.

Re:Direct Competition?

[buglista]

NO, THEY ARE NOT. They are not even based on the 6502, it was a new design of 32-bit RISC processor which came out in1987, which is when I first had a play with an ARM-based computer. Look at the instruction sets if you don't believe me.

And who modded this complete rubbish up to 3 anyway?

Re:Direct Competition?

[peppepz]

You can read more in the slide 4 from ARM's presentation at http://www.arm.com/files/downloads/ARMv8_Architecture.pdf:

- Fundamental motivation is evolution into 64-bit
- - Ability to access a large virtual address space
- - Foresee a future need in ARM’s traditional markets
- - Enables expansion of ARM market presence

- Developing ecosystem takes time
- - Development started ahead of strong demand
- - ARM now seeing strong partner interest in 64-bit
- - -Though still some years from “must have” status

Re:Direct Competition?

[Anonymous Coward]

ARM is RISC and the 68k is CISC

That is the information you get if you look at wikipedia. If you look at the instructions set and reference manuals of the CPU's you might get another idea.
The difference between the MC68000 and the MC68060 alone is large enough to question the validity of categorizing an entire CPU family into the RISC/CISC group.

Re:Direct Competition?

[Anonymous Coward]

It's not low wattage on itself, it's performance per watt. Low wattage "per se" is important on mobile devices, not on datacenter.

Re:Direct Competition?

[aztracker1]

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.

Re:Direct Competition?

[Anonymous Coward]

Right you are. x86 was seen as a badly-designed, amateurish architecture based on the older z80, which would get crushed by the up-and-coming RISC architectures. It turned out that high-volume commodity processors and boards beat the RISC stuff handily when it came to price/performance, and the influx of cash helped Intel ramp up its R&D to make better and better processors, both in terms of silicon processing and design.

Intel would do well to remember these lessons now that /it/ has a near-monopoly on the high-end, high-margin processors (Xeon). ARM-based processors are being produced in enormous volume for smartphones, tablets, and set-top-boxes, and if there were a standardized boot process and hardware baseline, they could replace the PC platform in very short order.

(I'm an engineer at Intel, and awfully proud of it. Posting anonymously for hopefully obvious reasons.)

Re:Direct Competition?

[Anonymous Coward]

Underneath the thin skin of the current x64 decoders are hiding high performance monsters. It is going to take much more than just 64 bit addressing and ramp up of the CPU clock speed to catch them.

Don't expect the 600 ton gorilla that is a x86/64 that was able to crush pretty much everything on it's path to sit idle and wait for own demise.

Re:Direct Competition?

[smash]

You do realize that the ARM processors are based on the old Motorola 68000 series of processors

Do you realise that you are talking out of your arse, and that ARM was developed as a totally independent architecture from scratch - the Acorn Risc Machine? And that the old 68k is in no way RISC?

Re:Direct Competition?

[smash]

All 68k CPUs are 32 bit internally, not 16 bit. The 68000 ran a 16 bit bus, but as far as instruction set goes, 68k has been 32 bit since day one.

Re:Direct Competition?

[Anonymous Coward]

...ARM is RISC and the 68k is CISC...

In my mind, ARM is not really a RISC machine - not pure RISC anyways. It takes a variable number of CPU clock ticks to perform some instructions. That is to say. not all instructions execute in a single cycle. Pure RISC machines like MIPS can even effectively do a branch in a single cycle. I say "effectively" because of the sneaky way MIPS eliminates the pipeline bubble during branching.

Maybe the smart people can answer this. Exactly how CISCy and how RISCy is ARM arch? What other instructions take more than one cycle on ARM arch?

Re:Direct Competition?

[Anonymous Coward]

Not Xeon workstations, no, but netbooks, nettops, and other consumer-grade non-gamer desktops? It's already there. The D2plug is like the Sheevaplug's Megazord form, with a gigabyte of RAM and an ARMv7/NEON core. Slap on Ubuntu, Fedora, or Debian, and it's perfectly usable.

Re:Direct Competition?

[Arlet]

Not quite. The ALU was 16 bits, so instructions dealing with 32 bit operands were generally slower.

Re:Direct Competition?

[msobkow]

*sigh* I hate being wrong, but I love being corrected. It's the only way to learn.

Re:Direct Competition?

[Pence128]

...the sneaky way MIPS eliminates the pipeline bubble during branching.

Hah! I knew someone must do this. None of this speculative execution or go both ways garbage, just keep executing instructions until the branch completes. If you're looping and don't have enough instructions, throw a couple of nops in there. All that headache goes away. Do it with arithmetic too: R1 = X, R1 = Y, R2 = R1, R3 = R1 gives R2 = X and R3 = Y. It becomes a pain to program in assembly, but compilers don't care and the CPU becomes almost trivial. If you have something embarrassingly parallel you can fit kilocores on a chip.

Re:Direct Competition?

[Anonymous Coward]

Do it with arithmetic too: R1 = X, R1 = Y, R2 = R1, R3 = R1 gives R2 = X and R3 = Y. It becomes a pain to program in assembly, but compilers don't care and the CPU becomes almost trivial.

If your instructions execute in a single cycle, sure. But if any of those are non-trivial (e.g., floating-point math), you've created a dependency chain, which compilers *do* have to care about.

Re:Direct Competition?

[Pence128]

That was the trivial example, but as long as the number of cycles is deterministic I think it's the same principle. The delay just becomes dependant on the instruction type instead of one cycle.

Re:Direct Competition?

[Burning1]

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 virtualization and blade servers.

If ARM can do more useful work with less physical space, cooling, and power, it will be a serious contender for Intel.

Re:Direct Competition?

[unixisc]

The x86 was lucky that Windows was not available on RISC, and that even after NT was available on MIPS and Alpha, most mainstream Windows apps, even from Microsoft, were unavailable for those processors. As a result, it didn't take much for Pentium-___ to beat MIPS or Alpha workstations that ran Wintel binaries under their OSs.

The situation now is quite different - this time, both ARM and Atoms have native support of whatever it is that they will be running, but only in the tablet space: in the PC space, those applications ain't there for ARM. Unless MS decides to write apps for ARM boxes running Windows 8 - something it never did for MIPS and Alpha boxes running NT.

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:Standardized boot process

[peppepz]

Alas, UEFI and ACPI are being ported to Arm. Most probably to let unmodified Windows 8 binaries run on different Arm boards (and to make Linux run awfully on them ).

Re:Standardized boot process

[Alioth]

Boot process is not a feature of the CPU architecture. Boot process is a feature of the motherboard that the CPU is on or the SOC that the CPU lives inside of.

I have an x86 machine that will not boot anything PC-like (a rather old Garmin handheld with an embedded 80386). The lack of a BIOS is more of a reflection that ARM is typically in embedded systems, not that you can't make a standard BIOS for one.

Re:Standardized boot process

[PickyH3D]

I don't think that the OP was suggesting that they can't make one. He was saying that they don't have one, yet.

Re:A CPU embedded in my genitals? Yes, please!

[antifoidulus]

I would absolutely love to have CPUs embedded in my genitals. That way I could mine some Bitcoins even while taking a piss.

And as an added bonus the heat given off will pretty much ensure you don't have kids.

Oblig. WAY

[rwa2]

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

64-bit CPU or 64-bit adresssing?

[Anonymous Coward]

The Commodore 64 CPU (Mos 6510, a variant of the well-known 6502) was not a 16-bit CPU. It had 16-bit addressing, but was still an 8-bit CPU.

Is this a real 64-bit CPU, or just a 32-bit CPU with 64-bit addressing?

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.

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

[unixisc]

The 64-bit logical address space, or even a physical address space means nothing. If the registers are 64-bit, the ALU has to be 64-bit, and the ALU is what defines the bitness of a CPU.

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

[peppepz]

The 68000 had 32-bit registers, but was universally recognised as a 16-bit CPU at the time.

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

[unixisc]

Why, was the ALU 16 bit?

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

[peppepz]

It's probable, but I can't find official documents confirming that. Motorola's manuals mark the processor as 16-bit because it has a 16-bit data bus. Similarly, Intel sold the 8088 as an "8 bit hmos microprocessor" for having a 8-bit data bus even though it probably shared its 16-bit internals with the 8086.

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

[unixisc]

Actually, a number of pentiums, starting as early as the Pentium, had 64 bit data buses, but were never 64-bit - they were 32 bit. That's b'cos the ALU has always been 32 bit. One of the advances in CPU technology did use more datalines for more parallel data transfers to & from the CPU, but without changing the ALU data width. And at the end of the day, if the integer operations one can do is 32 bit, then 32 bit is what it is.

Re:A CPU embedded in my genitals? Yes, please!

[Anonymous Coward]

But even at 1 cubic millimeter the chip is larger than your dick.

Re:A CPU embedded in my genitals? Yes, please!

[Anonymous Coward]

This should be modded up to infinity.

Law of diminishing returns

[Viol8]

Doubling the size of the registers requires a LOT of work internally to a CPU and is not done lightly - thats why 32bit held on for so long in the consumer world. Also there are 2 (main) types of bit measurement - address bus size and data bus size. An increase to 128 or more for the data bus size may be useful for some applications and that has already been done in some areas - eg graphics cards - but increasing the address bus size to 128 bits will bring no conceivable benefits as we're still a long way off being able to manufacture memory chips that can even approach the 2^64 bit size set by 64 bit never mind 2^128.

Re:Direct Competition? Already being demonstrated

[hmbJeff]

There are already several comanies working on multi-core ARM chips for servers, because they believe that will be the most power-efficient way to handle big workloads. Here is one product announcement from the day after ARM 64 was announced:

SANTA CLARA, Calif. – Applied Micro Circuits Corp. fired a shot across the bow of Intel, demonstrating the first 64-bit ARM server processor here. The X-Gene chip is the first of an array of competitors that will attack Intel's multi-billion dollar server franchise with cheaper, lower power ARM SoCs.

AMCC's X-Gene packs multiple 3 GHz cores complaint with the ARM 64-bit V8 architecture announced today at ARM Tech Con. The cores are quad-issue, out-of-order superscalar designs. The chip also sports Ethernet MACs, PCI Express and Serial ATA linked on an 80 GByte/second fabric.

The company showed a working version in an FPGA emulation it will ship in January. Silicon will sample in the second half of 2012.

Intel didn't invent BIOS

[Anonymous Coward]

IBM invented the PC BIOS. put that in your pipe and smoke it.

Re:Intel didn't invent BIOS

[tepples]

Which changes nothing. Please allow me to rephrase: At least one major computer maker invented a widely adopted standardized boot process for "god damn x86". This hasn't yet happened for ARM.

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.

Re:4GB is all it takes to break the barrier

[Anonymous Coward]

When you are at 2GB it starts to get a little tight, depending on how big the windows are

Oh my God. Are you stupid? Do you think a window no matter how big it is could take up 2 gigabytes of RAM? Windows take up pixels not memory. And if by chance you were talking about the operating system then you are really retarted as Windows only takes up a couple of hundred Megabytes. Maybe you are confused as to what cache is. Windows will cache up to however much available RAM you have so it looks like you are using 2gigs but you really aren't as the os will release as much memory as you need instantly.

Once you get 4GB then you really are stuck and have to use extended addressing and play highmem games in the kernel.

Highmem? This isn't DOS. We don't use "highmem" anymore. It's called virtual memory now or virtual address space. The program sees an infinite amount of memory and the system divvies it up to actualy RAM and swap space transparently to the app. Dude, you seriously need to step into the 21st century and put down the commodore 128.

Re:4GB is all it takes to break the barrier

[smash]

whoosh

Re:4GB is all it takes to break the barrier

[Pence128]

Serial/I2C ports need like, 16 addresses at the most. Are they really that wasteful?

Re:4GB is all it takes to break the barrier

[Anonymous Coward]

IOMMU

Re:4GB is all it takes to break the barrier

[OrangeTide]

Doesn't really solve this particular problem. IOMMU helps solve the issue of needing to map virtual memory to linear device memory, for things like framebuffers for scanout and textures. But you still have a 3/1 split and device drivers want to access a lot of address space while at the same time the userspace wants to access an increasing larger amount of RAM.

Re:4GB is all it takes to break the barrier

[OrangeTide]

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 simplifying the problem hardware faces.

Also a serial port might be seven 8-bit registers, but on ARM it's often impossible to do byte addressing on some of the buses, so they are 32-bit aligned. still less than 32 bytes of address space needed for an 8250.

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.

Re:ARM multicore problems

[rdnetto]

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 bootloaders derived from copies of Android, with closed source tools like nvflash if we're lucky (since without these there's no way to unbrick devices with bad kernels). I'm not an open source fanatic, but these are real stumbling blocks in the adoption of ARM - for example, nvflash can't handle images greater than 4 GB.

These basic problems preventing compatibility need to be given priority over performance issues. I'm not saying that performance isn't important, but it doesn't matter how well it handles parallel operations if we need a separate kernel for each implementation. We need to standardize these things before we can start pushing for adoption. Drivers are another issue entirely. (Even though the Android/Linux kernel is open sourced, wifi drivers are usually closed source and a lot of stuff is handled with closed source user daemons).

DISCLAIMER: I don't claim to be an expert on these matters by any means, I'm just someone who's been following (and using) the attempts at porting Ubuntu to an ARM tablet/netbook.

Re:ARM multicore problems

[Anonymous Coward]

Weak memory consistency causes some headache to the programmers. But saves a lot of work and chip area for the processor designer.

AFAIK the memory consistency logic of the processor limits the number of CPU cores that can be integrated onto a chip.

Re:ARM multicore problems

[Bengie]

An interview with AMD and Intel a long while back talked about how they want to move away from implicit cache coherency because of the scaling with core issues that you're talking about.

One of the ideas at the time was for the programmer/OS to have a way to signal threads for when a memory location changes, this way it would be more like a multi-cast instead of a broadcast.

Also, cores would be connected more like a network where each core/node is connected only to it's immediate neighbors, so keeping related threads near each other will be important, otherwise your communications will have more hops.

Re:Really needed... in five years?

[bingbangboom]

ARM is scaling up, while x86 is scaling down to get to this future "computing nirvana" where mobile meets desktop. I think x86, through AMD, is going to reach the computer/smartphone conversion line before ARM will. But the problem is the timeframe. Five years for ARM? AMD is at 2.1W for their tablet brazos chip with directX 11 and 64bit today. Meanwhile, Intel is just pissing around with Atom; their nextgen Cedartrail was thrown together with PowerVR graphics, can't even pass Win7 certification, and can only to 32bit DirectX 9.

64

[Anonymous Coward]

www.64.vc for sale.
info;carl@businessesman.com