ARM Attacks Intel's Netbook Stranglehold

Barence writes "British chip designer ARM is launching an outright attack on Intel with the launch of a 2GHz processor aimed at everything from netbooks to servers. ARM claims the 40nm Cortex A9 MPCore processor represents a shift in strategy for the company, which has until now concentrated on low-power processors for mobile devices. In the consumer market, ARM is pitching the Cortex A9 directly against Intel's Atom, claiming the processor offers five times the power while drawing comparable amounts of energy. 'It's head and shoulders above anything Intel can deliver today,' ARM VP of marketing Eric Schom claims. However, it has one major hurdle to overcome: it doesn't support Windows. 'We've had conversations with Microsoft and you can imagine what they entail,' says Schom."

Comments

Goody

[Hadlock]

Broken, first gen/beta ARM drivers for all my hardware!

Re:Goody

[TheRaven64]

Any half-decent OS (I think this even include Linux these days) uses the same drivers on multiple architectures with just an abstraction layer for dealing with the different busses. OpenBSD on ARM, for example, supports exactly the same set of USB devices as OpenBSD on x86, including things like USB video cameras. If anything, supporting multiple architectures improves the quality of the code. NetBSD and OpenBSD both recommend testing all drivers on x86 and SPARCv9 and this has helped find a lot of bugs that are not obvious on x86 but crash on SPARC, which has improved the drivers and benefitted x86 users.

What does it support?

[BadAnalogyGuy]

I suppose Ubuntu Linux is just chopped liver.

C'mon people. Wake up! There are tons of operating systems out there. Some are even better than Windows! *gasp*

Re:What does it support?

[QuantumRiff]

Just out of curiosity, does the ARM version of Ubuntu take advantage of some of the stuff in ARM for doing HD video at low power? Or is it just ubuntu, recompiled for the architecture? There are several advantages to each different CPU. Do things like Flash (or even Gnash) work on ARM? Or VLC, or anything?

A compelling Linux on ARM netbook will worry MS

[mikeabbott420]

Linux already made MS drop their price, allwing cheap windows netbooks because of linux. It's not out of the question that a really compelling ARM netbook would scare them into ARM support. I would be surprised if they didn't have something similar to the x86 apple builds in the powerPC era. Of course windows is mainly valuable for its 3rd party software so people who buy these putative ARM/windows machines may be better off with linux anyway.

Re:A compelling Linux on ARM netbook will worry MS

[sunderland56]

A Linux-based netbook won't worry MS if it only does what a MS netbook does. It needs to do more.

For example - they brag that the ARM "offers five times the power while drawing comparable amounts of energy". But, netbooks rarely use all of the processing power they have right now. If the ARM had equal processing power, but five times the battery life, they'd have a compelling product. The current standard of eight hours on a XP-based netbook is barely enough; a netbook that lasted forty hours would be a market breakthrough, and would be compelling enough to get people to switch to Linux.

Re:A compelling Linux on ARM netbook will worry MS

[Microlith]

The current standard of eight hours on a XP-based netbook

Having owned an XP netbook (aspire one) I must say that an eight-hour standard is optimistic beyond belief, and likely only possible if you leave it sitting there. The Atom processor is power hungry and once you start actually using it the battery life plummets considerably.

ARM already has an advantage on power consumption, if they can match the Atom on performance I suspect they'll win on battery life by default.

Re:A compelling Linux on ARM netbook will worry MS

[timeOday]

Whether the ARM chip performance is even adequate for normal netbook applications (e.g. watching youtube) is an open question until somebody tries it. Sure, ARM threw out this number of 5x, which is a meaningless number until we get a better overall idea of how fast and slow it is on different tasks.

Second, even cutting the CPU power consumption to zero wouldn't give you anywhere near 40 hours of battery life in a netbook. The CPU is just one piece of it.

Re:A compelling Linux on ARM netbook will worry MS

[IGnatius T Foobar]

Linux already made MS drop their price, allwing cheap windows netbooks because of linux. It's not out of the question that a really compelling ARM netbook would scare them into ARM support.

And Microsoft would still lose. The only thing Windows really has going for it is the existing library of PC software. That's the network effect that keeps Windows out front, otherwise the market would have dumped Windows ages ago. Windows on ARM runs existing Windows x86 software about as well as Linux does: not at all.

In fact, ARM netbooks running Windows might actually be at a disadvantage relative to Linux. People would see the Windows logo on the box and take it home, assuming that they could run PC-Windows software. When that software fails to load, the netbook gets returned to the store.

Netbooks running Linux on an ARM processor with insanely long battery life and a true dedicated mobile operating system may be what it takes to get people to realize that netbooks were not intended to be merely smaller laptops.

Re:A compelling Linux on ARM netbook will worry MS

[TheRaven64]

Note that watching YouTube is actually not a relevant benchmark for the ARM core. On most existing ARM SoCs, video decoding is offloaded to the DSP, ISP, or GPU and most of the A8 versions can decode 720p H.264 without any problems (and without touching the ARM core). SoC manufacturers like Freescale have partnered with Adobe to ship custom versions of Flash that take advantage of the extra hardware on the chip for exactly this. This means that an ARM chip will generally do a lot better, in terms of power usage, than Atom when watching YouTube because it's using dedicated hardware for the video decoding, while the Atom is doing it on the CPU.

Porting code to a new architecture

[Xocet_00]

What is involved in porting code to a new chip? I've done some programming in my life, but it has mostly been limited to personal interest and school projects. I imagine it can't be as simple as just recompiling. So what does it take to port code?What are the hurdles? Assume (accurately) that I'm a total noob.

Re:Porting code to a new architecture

[BadAnalogyGuy]

Let's say 30 years ago I gave you one end of an infinitely long piece of yarn and told you to start knitting a sweater. At first, it's not too bad. The yarn has a pretty standard consistency, although it sucks compared to some other yarn on the market. Then I start changing things up. Adding some knots and tangles in the yarn I hand to you. You do your best to accomodate and actually come up with a pretty nice sweater. Then you start re-designing the sweater to take advantage of the knots and tangles, and I just keep putting more and more complex knots in there since you seem to be doing great with the ones I've sent so far. Your sweater grows thick with piles of yarn and by the time 30 years rolls around, you've got yourself a pretty great sweater. Of course, you had some massive screwups like sweater ME and sweater Vista.

Now let's say I ask you to knit the same sweater using a beautifully crafted roll of thread.

I think you can see how hard that would be.

Re:Porting code to a new architecture

[TheRaven64]

It is either a complete rewrite, a simple recompile, or something in the middle depending on how different the architectures are. In terms of programmer-visible features (ignoring things only visible to compiler and OS writers), ARM and x86 are very similar; same word size, almost identical alignment constraints, same byte order. If you wrote your program in a high-level language, it is just a recompile. If you used any assembly language, then you will need to rewrite it. If you used a language somewhere in the middle, like C, then it will probably be a straight recompile. This is unlike porting, for example, from x86 to SPARC64, where you suddenly have very strict alignment, opposite byte order, and different

Of course, this is assuming the operating system interfaces are the same. If you're on something like OpenBSD, for example, then the OS does a good job of isolating the userspace code from having to know anything about the underlying architecture. Linux, on contrast, exposes a lot of architecture-specific details to programmers (and that's ignoring the fact that embedded Linux often ships with a non-GNU libc, which lacks a lot of features). Wince is about the worse at this, where every single device implements some subset of the Win32 APIs and so you end up having to do some tweaking for every device.

Re:Porting code to a new architecture

[timeOday]

Porting Windows itself is almost irrelevant. The tens of thousands of apps in the Windows ecosystem still wouldn't work.

Re:Porting code to a new architecture

[Knitebane]

I'm not sure I understand your analogy.

Does the sweater go on a car?

no windows?

[uncreativeslashnick]

This won't end well. I have an ARM device (nokia n810) and it's great. But Wintel monopoly will kill this just like it did Sparc and IBM Power. I'm sure if it's as good as they claim it'll carve out a niche, but it won't directly compete in numbers or presence with intel CPUs.

Re:no windows?

[TheRaven64]

There is nothing special about the ARM ISA that makes it require less power.

Yes there is. The ARM instruction set is simpler to decode than x86, which means that the (fixed) power cost of the instruction decoder is higher on x86 chips (you can't turn off the decoder as you can, say, the FPU or an adder while not in use because it's always in use unless the whole CPU is in power-saving mode). The Core 2 has to do a lot of clever stuff with the x86 instruction set because it doesn't match up at all well to a modern microarchitecture; not only does it split complex instructions into smaller operations, it also has to combine sequences of micro-ops into things that can be executed. Atom doesn't do any of these things, so it is a lot slower (per clock) in an effort to save power. ARM also gets to cheat a lot with things like Thumb code. This is a simpler, 16-bit ISA, which achieves very good cache density at the cost of some flexibility. You can switch ISA on a call with ARM chips, so you can have some routines in Thumb code and some in the full instruction set. Unlike the compression that Intel gets from a variable-length instruction set, this helps power saving because you can turn off the thumb decoder when it's not in use (and turn off the other instruction decoders when in thumb mode).

And that's ignoring things like the predicate instruction and barrel shifter that make ARM code denser and more cache-friendly than x86 code (which has the same advantage over something like SPARC). This means that ARM chips can get away with smaller instruction caches, which saves power.

If you want a more detailed explanation, Jon Stokes does a good job of explaining the advantages ARM has over x86 in his analysis of the Atom.

chip supports OS? Hmmm, backwards...

[kharris312002]

This may be the first time I've ever heard it said that a processor doesn't support an OS... Usually it's the other way around.

Re:No windows support?

[TheRaven64]

Clock for clock, the Cortex A8 is a bit faster than the Atom on most workloads (in about 10% of the power envelope). The A8, however, typically ships at about half the clock speed of an Atom (they go up to 1GHz, but 600MHz is the most common speed). The A9 is slightly faster than the A8 clock-for-clock, but goes to twice the clock speed and scales to four cores, so it's not a stretch to imagine that it's more than five times the speed of a single-core Atom. I've not seen any figures for the A9's power consumption yet though...

It's worth noting that ARM doesn't make chips, they are an IP-only company. ARM licenses designs to other companies who combine their cores with other stuff and ship them. One of the more high-profile Cortex A9 licensees is nVidia, who are using it in their Tegra line. Other existing ARM licensees, like Qualcomm, TI, Samsung and Freescale have already signed up for the A9 as well.

It's also worth noting that the A9 isn't really news. The designs have been available from ARM for a while now. I don't know of any shipping chips including A9 cores yet (being mass-produced, anyway; there are a few being sampled), but TI announced the OMAP4 series a little while ago which is based around the A9 and looks like a very nice chip for handheld machines.

Re:But, does it run DOS?

[TheRaven64]

People are willing to pay $15 more for XP (the cost of an XP Netbook license), but are they willing to pay $100 more for Windows (the difference between the cost of the announced ARM-based netbooks and a typical x86 model)?

Re:But, does it run DOS?

[Dog-Cow]

You are not all that bright. Some might even call you an idiot.

The ARM instruction set is not x86 compatible. End of story.

real solution

[99BottlesOfBeerInMyF]

There are a lot of barriers to Windows adoption on the ARM processor that go beyond MS not really wanting it. If they really want to gain market share above and beyond cell phones and PDA's, ARM needs a strong partner to create a real, integrated, polished solution. And by solution I don't mean a device. They need to do something akin to the iPhone, in creating a nice device or set of devices with a consistent polished operating system and with an integrated ecosystem of solutions. The project is large in scope and they need a partner that preferably has an existing position to leverage, experience, money, and which is not beholden to Microsoft. A cell phone service company might be a viable partner or Canonical and someone, or RIM or Google or an appliance maker that has not entered the netbook market yet.

If they really want to sell netbooks with ARM processors in them they have to think big. They need to better than hope MS is scared. They need to commit to building a system that bypasses MS's core monopolies through vertical integration. This is no small task. They need the hardware, which has to be cheap and hit a sweet spot. They need an OS and applications. They need dev tools for applications and services. They need Web and network services integrated with the device. More than all those pieces which are out there, they need someone to put it all together in a nice package and usability test the whole user experience from buying to opening the box right up through using it for all the common tasks: Web surfing, E-mail, chat, word processing, potentially phone calls and videophone, playing games, playing music and video, and adding new applications. The problem with a lot attempts at this sort of thing is the assumption that someone else will take care of parts or that blaming someone else somehow makes a failure better.

Re:real solution

[jabjoe]

The iPhone is a ARM processor.....

No Windows? Great! No Microsoft tax!

[MoxFulder]

However, it has one major hurdle to overcome: it doesn't support Windows.

Fuck Windows. Seriously.

I've been unwillingly paying the Microsoft tax for TEN YEARS. All I ever do is wipe Windows and install Linux. If my new computer can't run Windows then... great!! Maybe I won't have to pay the tax.

I'd love a low-power, high-performance ARM notebook. I'd be happy with MIPS or Loongson (Chinese MIPS clone) as well. Debian already has a full-blown ARM port and I'll bet they could get it working on an ARM netbook in a day. Ubuntu would undoubtedly be soon-to-follow.

As a side benefit, having multiple widely-used architectures for desktop systems (x86 and ARM) would be a support nightmare for hardware companies that still keep their drivers proprietary and undocumented. Yeah, I'm looking at you, Broadcom and NVidia. This would just be another nail in the coffin for their obstructionist attitudes towards free/open-source operating systems.

Re:No windows support?

[TheRaven64]

64-bit is a buzzword rather than a useful feature for most people. People with 64-bit SPARC or PowerPC machines generally run very little 64-bit software, because doubling the word size doubles the cache usage for no benefit (especially on SPARCv9, where integers registers are all 64-bit even when running 32-bit code). It's only important on x86 because 64-bit also means twice as many general-purpose registers, SSE required (no x87 ugliness) and a few other improvements. If someone defined an ILP32 profile for x86-64, where pointers were 32-bits but the chip ran in 64-bit mode then pretty much all code would be faster than the standard LP64 profile. On non-x86 architectures, 64-bit support is only important when you need more than 4GB of address space and are willing to pay a speed penalty for it.

32-bit only becomes a limitation on NetBooks when you start to get applications that can't fit comfortable in less than 4GB of RAM. This is not likely to be a problem for a few years. NetBooks may start getting more than 4GB of RAM in the next couple of years, but that doesn't require major changes, as long as the OS can address it and map it into processes' 32-bit address spaces (we still aren't getting many machine shipping with more RAM than a Pentium Pro with PAE can address).

Re:I will buy one

[flyingfsck]

Get a Touchbook: http://www.crunchgear.com/2009/03/02/touch-book-tablet-netbook-with-arm-cpu-10-hour-battery-detachable-screen/ It is already available and quite cheap.

Just for kicks

[Yvan256]

If anyone ever starts a new CPU-related company, can you please call it LEG for the sake of "it cost an ARM and a LEG" jokes?

Thank you.

Re:Just for kicks

[TheRaven64]

LEG should make DSPs or GPUs, so SoC manufacturers can include an ARM and a LEG on the same chip.

Re:No windows support?

[TheRaven64]

Look through the Slashdot archives for the article containing benchmarks - I am too lazy to dig it out. It is a gross mistake to regard ARM as a RISC architecture. It is in the sense that the instruction set is orthogonal, but it is incredibly dense (much denser than x86). Almost every instruction can be predicated on one of the condition codes, which eliminates the need for a lot of branching (and, therefore, reduces the overhead from superscalar designs) and every instruction gets free use of a barrel shift on the result. Added to that, most ARM chips from the last decade support one or more of the Thumb instruction sets, which are 16-bit versions of the ARM instruction set, and most ABIs let you switch between these on a per-function basis, so you can compile functions that don't touch more than 64KB of RAM into thumb code and get even better cache usage.

You'd also be surprised at SIMD performance. The Cortex A8 and A9 support both Neon and VFP vector instruction sets. They are not so fast for double-precision vector floating point workloads, but on single-precision and integer SIMD loads they do reasonably well. For very FPU-intensive workloads you are generally better off using the DSP that comes with most ARM SoCs.

The best thing about it

[the_womble]

it doesn't support Windows.

That's not a bug, its a feature.

Re:NO WINDOWS ARM APPS SO -- SO WHAT?

[hattig]

There are 75,000 apps for ARM iPhone OS X.
There are 10,000+ apps for ARM Android OS.
There are loads of apps for ARM Maemo.
There are loads of apps for ARM Symbian.
There are loads of apps for ARM Windows CE and derivatives.
There are loads of apps for ARM Linux and derivatives.

Re:chip supports OS? Hmmm, backwards...

[Locutus]

in the Windows world, you'll hear that the processor runs on Windows all over the place. They've been trained that Windows is the end all, be all, and center of the universe so the concept of "it runs on Windows" is their world. Talk about a CPU and _it_ runs on Windows is the norm. They really don't know how to think about it without Windows at the center or in a hierarchy of the hardware->OS->applications. They can't imagine a world without Windows. Combine that with software people and marketing people with no clue of hardware and you get "processor X doesn't run on Windows"

LoB

I don't think you know anything about Linux portab

[anti-NAT]

ility. It runs on more architectures than OpenBSD, and you're saying it's far less portable, and that the architectual differences are exposed? Way back in 2000 I ran (Debian) Linux on a Sun Ultra 5, and it just worked. The only issue I had was nmap, and that was likely due to a missing htonX() calls. OpenBSD wouldn't have magically put those instructions in the nmap code if they didn't exist either.

I've written networking kernel code for Linux, and never encountered any CPU specific requirements - it's all abstracted behind function calls.