ARM Attacks Intel's Netbook Stranglehold 521
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."
Re:Goody (Score:4, Informative)
Yeah. With a few exceptions, about the only variation between most netbooks out there in terms of required drivers are the following:
1) WiFi chipset
2) Card reader chipset (newer ones all seem to be USB mass storage, older ones tended to be a bit less standardized)
3) Bluetooth chipset (Bluetooth chipsets are basically standardized - While I know nonstandard ones exist, Bluetooth adapters that aren't a USB device compliant with a particular USB class are extremely rare.)
This is because the Intel Atom platform is EXTREMELY standardized. With a few rare exceptions, if you use an N-series Atom processor, it'll be paired with one of two variants of the Intel 945G chipset with GMA950 graphics.
Atom Z-series are a different story - they are all paired with a particular chipset with "GMA500" graphics, which unlike most Intel chipsets has basically nonexistent Linux support. So never buy an Atom Z-series based machine if you want to run Linux, they are nearly always paired with unsupported graphics.
Re:Will ARM compete? (Score:2, Informative)
No, but NVidia has gone ahead and integrated ARM [nvidia.com].
Re:No windows support? (Score:5, Informative)
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:What does Linux on ARM support? (Score:1, Informative)
Yes
No, Wine is designed to run x86 windows applications. It doesn't emulate a different CPU.
No, Virtualbox is a purely x86/amd64 solution. It uses hardware virtualization in your CPU, it doesn't emulate a different CPU. You're looking for QEMU.
Maybe with QEMU, it has some application level CPU emulation, interested parties might make it work in that case.
Re:Porting code to a new architecture (Score:3, Informative)
It depends on how the original code is written. In a well-structured OS like Linux and NetBSD, they isolated the idiosyncrasies of the CPU and focused on using common high-level features across most CPUs (memory paging and interrupt handling among the chief of them), and can optionally adapt when a particular feature is not available on some architecture (e.g. high resolution timer, atomic instructions). In such case, porting to a new architecture just entails writing the assembly language glue that bridges high-level hardware feature with the machine instructions that does the real work.
But among the worst things you can do is to hard-code low-level hardware handling and scatter that throughout the source code. Or some important code may be overly dependent on CPU specific feature (e.g. task gate for intel x86) which makes it essentially non-portable. I've never seen the source code of Windows, but I suspect this is the case with them. According to some Windows NT Internals book I read many years ago, it started out well-structured, with a nice hardware abstraction layer and all that. But since Windows dropped Alpha processor support, I think the abstraction started to suffer bit-rot and made things much worse than if they had no abstraction at all.
Re:It's time for apple to step in (Score:3, Informative)
Actually, microsoft supported non intel before. Anyone remember the DEC Alpha chips? There was an NT flavor for that. It ran faster then the intel chips of the day.
It would not surprise me that in an microsoft lab there was windows for power PC, windows for ARM, windows for . It would be in microsoft's best interests to have them.
Re:What does Linux on ARM support? (Score:3, Informative)
A) much simply needs recompiled, if it doesn't - with an app with the source - it's usually a bug.
B) No - wine is simply a conversion layer between the windows and linux calls - the windows program is never emulated.
C) No - again - not without emulation.
D) I think you can probably guess this one - but again no.
Emulation may be _lots_ slower than the host processor - slowdowns of ten times or more are not uncommon.
Re:But, does it run DOS? (Score:1, Informative)
There has been an X86/MS-DOS emulator for ARM since 1987, I used it then to make my Modula-2 assignments :)
http://www.cbronline.com/news/ms_dos_for_acorn_archimedes
Re:Porting code to a new architecture (Score:5, Informative)
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:What does Linux on ARM support? (Score:3, Informative)
It depends on the distro. Debian has a complete ARM-port, Ubuntu was working on one last time I checked. Maemo is an ARM-only distro.
Nope.
Nope.
Not likely (assuming these are binary blobs). Flash video, avi/mpeg's and various other formats shouldn't be a problem though.
An ARM netbook wouldn't be someones only PC, just like current netbooks aren't. If it can do 90% of the things you're used to you're set.
Re:But, does it run DOS? (Score:1, Informative)
ARM processors (including Cortex series) have an entirely different instruction set from 80x86's. That's pretty much the definition of x86-incompatible. Whether it runs windows is an entirely different matter (but don't hold your breath on that either).
Re:Will ARM compete? (Score:3, Informative)
Just to put things into perspective, the Pandora ships with an OMAP3530 and will have as one launch "title" a PlayStation emulator, which has already been demonstrated to run smoothly. We're talking about something the size of a Nintendo DS that has a projected battery life of 9+ hours playing games off a 4200 mAh battery, capable of emulating the PSX. The Cortex A8-based OMAP3 is a seriously powerful little beast. I don't expect the Cortex A9-based OMAP4 to be any worse.
Re:No windows support? (Score:3, Informative)
It doesn't look like we'll have to wait too long to see these implementations in action either. Schorn reckons we'll be seeing ARM ecosystem products containing Cortex A9 designs in the first half of 2009 and then Osprey related silicon to appear later that year.
From the Hexus Article..
It sure would be nice to have an update to that linked article that was written a year ago. I've seen lots of info on ATOM since then, but not much on the A9 systems that should already be out.
Re:A compelling Linux on ARM netbook will worry MS (Score:5, Informative)
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:No windows support? (Score:5, Informative)
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:A compelling Linux on ARM netbook will worry MS (Score:5, Informative)
Re:no windows? (Score:3, Informative)
I wouldn't be so sure about that. There are significantly more ARM devices out there than x86, Sparc, and Power combined.
This is not true. PowerPC is doing very well; it is in every current-generation console and most new cars. If you buy a BMW, you are getting something like 40 PowerPC chips for the various control functions. In automotive and industrial control applications, PowerPC is the dominant player. SPARC is doing less well, although it has, I believe, the highest market share once you leave the atmosphere (radiation-hardened SPARC chips are very popular on satellites, helped a lot by the fact that ESA funded the development of open source SPARCv7 designs).
Re:No windows support? (Score:5, Informative)
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.
Re:What does it support? (Score:4, Informative)
linux has held pretty steadily at sub-1%
Steve Ballmer says otherwise [osnews.com]
Re:no windows? (Score:5, Informative)
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.
Re:NO WINDOWS ARM APPS SO -- SO WHAT? (Score:4, Informative)
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:The best thing about it (Score:4, Informative)
Re:Porting code to a new architecture (Score:1, Informative)
This has nothing to do with arm and everything to do with the compiler.
I don't think you know anything about Linux portab (Score:5, Informative)
I've written networking kernel code for Linux, and never encountered any CPU specific requirements - it's all abstracted behind function calls.
Re:No Windows? Great! No Microsoft tax! (Score:3, Informative)
Doing so incurs a performance hit, quite a significant one, as well as using extra memory.... When DEC did it with the Alpha, current Alpha processors were hugely faster than any available x86 so even with the performance hit you got comparable or better performance than using a real x86 system. ARM processors are not as fast as current x86, and the performance would be so poor as to eliminate the benefits ARM has over Atom.