ARM chips put on their server boots
Intel fight afoot
The ARM RISC processor is taking a few baby steps closer to being a credible alternative to x64 processors for servers, according to ARM Holdings, the British company behind the popular chip.
According to notes for a speech delivered at the Hot Chips conference at Stanford University on Tuesday, ARM Holdings architecture program manager David Brash says that the ARMv7-A architecture design – which licensees are allowed to customize as they see fit – will have a new feature called large physical address extension. This will translate 32-bit virtual memory addresses to 40-bit or larger physical addresses.
The idea, according to Brash, is to "ease pressure on the 4 GB limit for I/O and memory" in the current 32-bit designs for top-end ARM chips. At 40 bits, one terabyte of main memory could be attached to a 32-bit ARM core and the two-stage memory address translation does all the shuffling to make the core think it is just using a 4 GB memory space.
The question is whether this shuffling and memory virtualization is going to eat up more power than just adding true 64-bit memory addressing to the chip anyway. But then again, on a lot of servers, it is not like an operating system is really under control of its main memory these days. RISC and x64 servers in the data center, where ARM chips might get some play, tend to get virtualized and carved up into pieces by hypervisors anyway. So as long as the hypervisor is designed in cahoots with the memory virtualization technology, then this could all work out rather nicely.
As it just so turns out, Brash said that the new virtualization extensions to the "Eagle" architecture, as the ARMv7-A design is code-named (the chips are also known by the Cortex brand), has a set of virtualization extensions in the silicon that give a new privilege level for a hypervisor running atop the ARM chip, and the two-stage address translation works on a raw operating system owning the whole ARM chip or for a hypervisor that lets guest operating systems think they own the whole chip when they most assuredly do not.
ARM has talked about how it will assist the virtualization of CPU cores and memory on the ARM chips, but has yet to describe how it will virtualize I/O, something it will eventually have to do just as x64 chips have had to do.
For plenty of workloads, such as Web serving or big data crunching, 32-bit is enough memory to get the job done so long as the server has enough I/O bandwidth to move data from disk storage and the network into the machine and information that has been chewed on back out again. For these kinds of jobs, which are typically written for Linux and are therefore fairly portable, the issue really comes down to performance per watt, not legacy application instruction set compatibility.
There are over 15 billion ARM chips that have been shipped since 1990, and at the moment there are over 200 companies that have licensed over 600 ARM RISC chip designs from ARM Holdings. Some 95 percent of the mobile handsets and one quarter of all electronic devices worldwide are using ARM chips. There is a vast amount of knowledge out there about how to tweak the ARM design, and a huge base of programmers who are intimate with its architecture.
And that is why ARM scares the hell out of Intel a lot more than Advanced Micro Devices ever did. Oddly enough, Intel had its own XScale ARM chip business, which it got from Digital Equipment in 1998, which was subsequently sold off to Marvell. Intel may regret that move, but all it need to is shell out some money to ARM Holdings and it can jump right back in again.
That seems unlikely, of course. And besides, it will be much more fun for the rest of us if ARM becomes a credible alternative to the x64 architecture for servers, netbooks, and maybe even other PCs at some point. Stranger things have happened.
Brash said that the specification details for the architecture extensions would be available by the end of this quarter, and that ARM's own implementation of the new features was "well advanced."
If you want to dive into the feeds and speeds of the new virtual memory addressing and hypervisor extensions coming with the ARMv7-A, you can see Brash's presentation from Hot Chips here.
Interest in ARM-based servers is growing as power and money budgets alike remain constrained despite some loosening in the global economy. As El Reg has previously reported, a startup called Smooth-Stone has bagged $48m in cash to pursue the idea. There are rumors going around this week that social disease media giant Facebook is going to put ARM-based servers into its data center in Oregon, and it would not be at all surprising if Apple had created ARM-based servers for its massive North Carolina data center.
You think Apple wants to use Intel's chips, or its own? You have to figure that Steve Jobs would put Apache on a million iPads - with all their skins and screens removed - before he'd cut a check for a couple hundred million bucks to Intel just to serve up iTunes. Google will always do what is best for Google, of course, and if it doesn't have an ARM server skunkworks, then it deserves to be knocked out of business by Microsoft's Bing. ®
COMMENTS
"I remember the launch of Windows NT"
Best TPM article for yonks. Best of luck to ARM. But they've got an uphill battle on their hands, and not just at a technical level.
"I remember the launch of Windows NT"
But maybe you don't remember it very well.
"The Hardware Abstraction Layer - yeilding the choice of PowerPC or Intel. It never worked."
It may never have worked on your PowerPCs, I don't know.
In the rest of the world, it was also supposed to work on any conforming box from the Advanced RISC Computing consortium, whose members used not just PPC but MIPS and Alpha.
The HAL concept worked fine on the NT/Alpha boxes I used, from Multia to AlphaStation 400 to DIGITAL Personal Workstation PWS500a and indeed various DIGITAL Server boxes. I probably still have the relevant MSDN CDs somewhere, paid for by my (not my employer's) money.
At least, it worked as far as Gates allowed it to, and as far as the pre-virtualisation miracle that was FX!32 allowed it to. FX!32 was DEC software for NT/Alpha that allowed on-the-fly translation (not emulation) of x86/Win32 apps to Alpha/Win32 apps, as had been pioneered earlier by their VAX to Alpha translators.
Other ARC players didn't have equivalents of FX!32 so they were even more reliant on recompiled-to-native versions of Windows apps, which of course Gates never really provided except for x86.
Then after a little while Gates said to DEC: "You can either be Larry's friend or you can be my friend" and DEC's top folks didn't choose Bill. The rest is history.
Speaking of history, now that the history of massive anti-competitive backhanders and/or commercial blackmail (call it what you will) over many years between intel and Dell is finally emerging into daylight, it would be interesting to know what kind of sweetheart deals went on between Intel and Microsoft so that Intel didn't have to face any real competition in the chip market. I know from personal experience that Intel were quite happy to twist people's arms if they were threatening to look at AMD in any significant way.
Fortunately that kind of rubbish doesn't (can't) go on in the open source market.
Gak
Didn't we finally get all that address-obstuficating-workaround-hack clutter *out* of the x86 arch? I'd prefer something very ARM-like but with a re-structured instruction set around a 48-bit flat address space. Or an x86-64 with all legacy instruction/addressing modes stripped might be interesting.
It's heartening to know that Britain actually makes something ...
along with Cornish Pasties and Peas Pottage since they no longer have domestic manufacturing as they once did in Morris, Leyland, Plessey, Marconi, etc. Even screw, nuts and bolts are imported.
Even my Wellington Boots have 'Made in China' on them, as do 'Saville Row' suits (most are made in ShangHai nowadays).
Let's hope some some overseas conglomerate doesn't buy up ARM Holdings and that it continues with it's technological prowess. A British winner.
"even on x86-64, the full address space isn't implemented"
Lou, don't forget there's a difference between what a chip architecture supports in principle, and the subsets which may be implemented in any particular implementation of an architecture. x86 isn't an architecture, it's a collection of engineering kludges with an extensive set of supporting software.
PDP11s were nominally a 16bit architecture but you could have 4MB of memory on some of them, so more physical address space than logical address space is not exactly new to the world. The magick lies in doing it cleanly so that transitions between different implementations don't cause nightmares (eg if "clever" people have found creative uses for "unused" address bits, e.g. "to save space").
AMD64 seems reasonably clean in this respect (it's not really x86-64 is it, whatever Intel would prefer).
Yes, confused. So?
Yes people have been confused about this since the days of '16-bit' (8088) and '8-bit' (8080) software, since both of those machines had 8-bit data bus, and 8-bit and 16-bit registers (but the 86 squeaked in with a few more 16-bit arithmetic ops) And the 68K was 24A/16D on the pins.
So what's your point? A convention that was barely meaningful when started in 1982 needs to be still followed? Bear in mind you still don't need 64-bit arithmetic for much, but 64-bit addressing is of critical importance for getting more ram online, and if you have 64-bit user addresses then you need 64-bit arithmetic to calculate addresses. If you have 64 bits only in the MMU, you can run a vast range of apps sharing terabytes of PM as long as each one doesn't need more than 4G of VM. Like everyone running all those x86 apps under Win64. So, at this point in history focus has shifted from the size of the data registers to the size of the address (I could also point out that a fair number of '32-bit' processors have had 64-bit data busses, and 128-bit vector registers supporting 64-bit arithmetic).
Bottom line, people will continue to be confused about what ' 64 bits' means wrt to CPUs, unless it's provided with some other info, e.g. AMD64, or iA64, or '64-bit physical address'. Do you think it would be a good thing if 'Oh, it's got a 64-bit CPU' actually told you everything you needed to know? Confusion is OK when it forces clarification.
