What's so great about ARM?

Question

In a comment to this answer Kortuk asks what the ARM advantage is. I first added some arguments in my answer, but I think the question is interesting enough to be a question in itself, so that more answers are possible.

Answer 1

Performance is one advantage. Being a 32-bit processor it outperforms (almost) all 8-bit controllers DMIPS-wise. The core also has gone through several generations, read optimizations.
These optimizations not only show in performance numbers, but in power consumption as well. The most recent core has doubled its DMIPS/mW ratio compared to the previous generation (see also this answer).
ARM is available from a great many manufacturers, more than any other microcontroller, and each has a number of versions to choose from, with different combinations of on-chip peripherals and memory, and packages. Case in point: NXP offers no less than 35 controllers with on-chip Ethernet.
ARMs are inexpensive; ARM was probably the first 32-bit controller to break the USD 1 barrier.

This combination of performance, wide offering and low cost make it such that you simply can't ignore ARM:

In 2005 about 98 percent of all mobile phones use at least one ARM-designed core on their motherboards, according to research from the analyst firm the Linley Group. (source)

The mobile phone market has also another effect. Mobile phones are very space constrained and demand small packages. NXP's LPC1102 comes in a WLP-16 package just 5mm\$^2\$, a scale previously only used by low pin-count 8-bit microcontrollers.

Answer 2

One point not yet mentioned: In 1908, a guy named Mr. P.L. Robertson invented a new improved screw head and driver. He wanted to be the only person to manufacture screws and drivers to his design. Decades later, someone else named Mr. Henry F. Phillips came up with an alternative design. Unlike Mr. Robertson, Mr. Phillips was more interested in licensing his design than in producing screws and drivers.

Likewise, in the 1970s, Sony came up with a technology called Betamax; JVC came up with one called VHS. Sony was interested in producing VCRs; JVC was more interested in licensing.

There seems to be a pattern here. (Note: For awhile, Intel did license its 80x86 technology, but it has for decades been focused more on developing technologies for its internal use.)

Answer 3

1. Same hardware/software to develop for ARM's of all vendors. You buy JLINK/ULINK and some Keil IDE once, and can use it to develop, emulate and debug nearly any ARM on a planet.

2. No need to learn new architecture when moving to new chip vendor => less vendor lockin => more competition => lower prices

3. In modern tech-processes(0.18um and below) ARM core is so tiny, that sacrificing it for 8bit core would not save any visible fraction of a price. Hence the reason of going for standard high-performance yet cheap architecture.

4. Performance - only with ARM you can have single clock 32*32->32 multiplication and hardware support for 32*32->64 and division for sub-1dollar devices (namely, lower-end STM32's for example)

5. ARM is not too greedy, and does not charge unreasonable fees for licenses, so manufacturers can produce cheap micros.

Answer 4

I'm focusing on mid-range ARM processors for these reasons:

1. Full Linux support

   This means device drivers almost for free. I've done enough USB host and device code, I don't want to do THAT any more. I'm also not too thrilled about trying to add TCP/IP to a random processor platform (although LwIP/uIP isn't that bad). I never even tried doing Wi-Fi, a real Bluetooth stack, webcams, etc. Using Linux means a very broad array of devices become much easier to talk to.

   I was also really amazed at how rational and easy writing Linux device drivers is. After doing some Windows device drivers Linux is a dream. (To be fair, the Windows driver framework has improved a lot since I was doing it.)

   The software platform is also awesome. I get SSL encryption, filesystems, remote management, easy application updates (copy a file over instead of a complex bootloader), etc. Oh, and lots of existing utilities if you need something done.

   It's also royalty free and much easier to bend to your will than say a closed source WinCE platform would be. (Not that I'm really much of an open source idealist... it's all very practical reasoning for me.)

   I am talking about ARM cores with actual MMUs, so this is for the mid- to high-end chips (although you could use μClinux I suppose).

2. Power consumption

   This is basically a repeat of other's comments, but it's a big factor for me. My current 454 MHz ARM platform draws 1/2 a watt, 1 watt at max CPU. You can't even get close to that with x86.

That's pretty much my reasoning. I don't see the equation changing any time soon.

Answer 5

The ARM has gone through a progression:

1. A 32-bit-instruction architecture, which had bulkier code than many other architectures, but which could be decoded quickly and could do many operations with fewer instructions than competing architectures
2. A dual-instruction-format architecture, which could switch between the nice and powerful (but unfortunately somewhat bloated) ARM instruction set, and a less powerful (but far more compact) 16-bit "Thumb" instruction set. Every Thumb instruction had a corresponding ARM instruction, minimizing somewhat the need for programmers to learn two instruction sets.
3. A Thumb2 architecture, which added two-word instructions to the Thumb instruction set, yielding what's mostly a win-win: typical ARM code would contain a mix of instructions that were only available in the ARM, and instructions which would have been available in Thumb but had to be represented as 32 bits anyway; in Thumb2, such code gets the space benefits of replacing some of the 32-bit instructions with 16-bit ones.
4. A Thumb-only architecture, which is more limiting than I'd care for, but which is smaller and cheaper than any of the others.

The ARM architecture allows for some rather sophisticated operations to be performed very quickly--far more quickly than on any other chip. For example (using ARM7-TDMI):

  ldrh r0,[r10,#ADDR_BUS_OFS] ; Read target system address bus (13 bits)
  ldrb r1,[r9,r0,lsr #8]  ; Use upper bits to look up address in a table of handlers
  add pc,r9,r1 lsl #2    ; Go to appropriate handler

Each handler is stored as a byte, which gives 1/4 of the address displacement from the start of the table. Net effect is that once the contents of the address bus have been fetched, it takes only six cycles (two instructions) to jump to a handler based upon the upper five bits of the retrieved, using a 32-byte jump table.

Corresponding THUMB code would be more like:

; Assuming we don't need r6/r7 for anything else, they're reassigned from r9/r10
  ldrh r0,[r7,#ADDR_BUS_OFS]
  mov r1,r0
  lsr r1,r1,#8  ; THUMB requires source and destination to be the same
  ldrb r1,[r6,r1]
  lsl r1,r1,#1  ; Could use shift-left-two, if target addresses were full-word aligned
  add pc,r1

That's fine from a code density standpoint, given that the instructions are only half as big as the originals, but would take nine cycles after the fetch rather than six. In an application where the bus being watched is going to run at its own speed whether or not the ARM has managed to handle it, the faster ARM instructions are a big plus.

Incidentally, Thumb2 is binary compatible with Thumb, which facilitates use of earlier tools, but means there are some things it can't do as well as the original ARM. For example, in ARM, one could "rotate" an 8x8 bitmap held in four registers using about 3 instructions per two bits:

  movs r0,r4,lsl #25  ; Put top bit of LSB into C and next bit into N
  orrcs r6,#0x00000001
  orrmi r6,#0x00000100

In Thumb2, it would be necessary to add explicit conditional instructions:

  movs r0,r4,lsl #25  ; Put top bit of LSB into C and next bit into N
  itcs
  orrcs r6,#0x00000001
  itmi
  orrmi r6,#0x00000100

Net 33% reduction in time and space efficiency compared with ARM; that's probably about a worst-case example of Thumb code being less efficient than ARM, and even that's not exactly horrible.

One other slight disadvantage of Thumb2 compared with ARM: in ARM code, all instructions start at full-word boundaries, facilitating static analysis. In Thumb2, instructions can arbitrarily start at half-word boundaries and straddle full-word boundaries. Static analysis can thus be much more difficult.

Answer 6

A bit is history, Acorn wanted a custom CPU (e.g. with built in memory controls etc) for a new computer in the 1980s (The 8 bit 6502 was limiting what they could do). They talked to Intel, but Intel would not the licenced a CPU to them.

So Acorn designed a very simple RISC CPU, but as they were not a CPU manufacturer they were willing to licence it to anyone (and needed all the quick money they could get!). (I believe the CPU worked first time, partly because it was so simple and also the designer has created lot of research CPUs while at Cambridge University.)

Over the years the CPU design become easier and easier to include in customer chip design.

Chip manufacturer felt safe licencing from Acorn as they were not a competitor. Also no one thought they were going to a competitor’s home town to get a licence, as Acorn was in Cambridge (the real one!). (Did the chance of a “fact finding” trip to Cambridge so as to visits Acorn influences shorting listing of options at any point….)

A lot of the designs that include the Acorn Risc Machine CPU were for embed system were power usage was important. Cheap and good development tools were also created for the Acorn Risc Machine CPU.

So when mobile phones started to need custom chips with an embedded CPU, Acorn was renamed ARM and the rest is history. (Maybe it was also a bit that the other CPUs were mostly controlled by the USA, but mobiles first become normal in Europe)

(Does any of this remind you of Microsoft and Dos with a small unknown team from IBM?)

The fact that the ARM was one of the best CPUs at the time (and still is) for a lot of tasks did help as well - but just having the "best" CPU design is not enough.

Answer 7

Technical issues aside, there are lots of non-technical reasons for ARM. But the quick answer is this: It's not Intel (or x86).

If you looked at where the CPU R&D dollars are being invested right now they fall into basically two camps: ARM and Intel. (I'm ignoring small MCU's, and I'm lumping AMD in with Intel.) There is very little money going into PowerPC, MIPS, SPARC, and other large CPU's. ARM and Intel are the only ones still standing.

With Intel and other x86 CPU's you get a huge amount of legacy baggage. For example, you need a chipset, a BIOS, and other stuff. Even if the CPU was super power efficient, those other devices tend to weigh down your system and make it bigger, more power hungry, and more expensive. Just developing a PCB with an Intel CPU is a huge issue, and then you have to negotiate with a BIOS vendor, etc. To make matters worse, many of the vendors for chipsets, BIOS's, video chips, etc. simply don't want to do business with the small folks who won't sell less than a million units a year.

With ARM, you don't have that baggage. There are many sources of chips from microcontroller-line things up to multi-core monsters. You don't need to deal with licensing a BIOS (which is much like going to a used-car salesman). And manufactures and vendors are generally nice to you.

Answer 8

Compare ARM7/ARM9 to MIPS IV and there is little advantage other than licensing issues already well mentioned. The internals of the MIPS instruction set and internal bus make it superior (performance per cost) for certain types of designs; which is why many Wi-Fi routers use MIPS cores rather than ARM cores.

Since ARM cores were applied mostly to handheld devices the ASICs added more power control features whereas MIPS focuses more on performance per cycle rather than lower power. The benefit of RISC over Intel x86 is a different discussion.

Answer 9

There are no real advantages. Attached DSP and other controllers, like GSM is what make them so popular.