# What's so great about ARM?

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.

## locked by Dave Tweed♦Aug 22 '16 at 13:11

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. See the help center for guidance on writing a good question.

• your answers seem to be constructive on the least constructive questions, but I worry others will write very opinionated answers. We will see if people attempt to hurdle the bar you have set. – Kortuk Jul 14 '11 at 12:24
• @Kortuk - Feel free to edit the wording of the question or the title if you think it may help to get better answers. (It was your question anyway) – stevenvh Jul 14 '11 at 12:31
• This questions is asking for a religious war. If it weren't for the people asking and commenting, I'd be voting to close this immediately. Remember, you know you're always right and the other guy a barbaric heathen when it's a matter of faith. Let the jihad begin... – Olin Lathrop Jul 14 '11 at 15:15
• @olinLathrop, that is what I am watching for. Currently it seems like we are getting very high quality answers without bickering. I will probably make this a CW long term and allow the google bait coupled with interesting information on arm to live. I would have normally closed this outright but @stevenvh did open it with a great answer and seems to have set a tone of quality. – Kortuk Jul 14 '11 at 15:47

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.

• I can only add, that ARM definitely first 32-bit micro to break 0.5\$ price point (Cortex M0 in quantiny) – BarsMonster Jul 18 '11 at 1:26
• @Barsmonster - Cool! Looks like the only future for 8-bit is in 2mm x 3mm DFNs – stevenvh Jul 18 '11 at 4:31
• @self - and maybe not even that. See the addition about the LPC1102 in my answer. – stevenvh Aug 16 '11 at 10:27
• @stevenvh - Well there is still the power consumption advantage. LPC1102 @ 12MHz sleep mode uses 1mA. Not bad, but about 1000 times more than a [16 bit] msp430. – Imbrondir Oct 14 '11 at 11:10
• @self - Scratch that advantage too. After some searching it seems Energy Micro has a M3 that in sleep mode + RTC can get down to 0.6uA. – Imbrondir Oct 14 '11 at 11:43

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

• Yes. I think the licensing scheme for ARM intellectual property is the cause of success. – user924 Jul 14 '11 at 15:33
• ARM allows a huge amount of flexibility with its licensing. If you just need the IP for a couple cores, it doesn't cost too much. But if you want to make a heavily-customized chip, fully optimized by your chip designers, that costs more but is an available option. So a company like Apple can go develop its own line of processors optimized for their application. Most companies wouldn't let that much of the crown jewels outside their control. – Mike DeSimone Jul 14 '11 at 18:02
• It's important to note that ARM doesn't compete with Intel's x86 line (not even really in the space that the new Atom processors run in). If your answer was meant to imply that, it's incorrect. Intel's Moorestown and Medfield architectures (are meant to) compete in the same space as ARM. – Mark Sep 26 '11 at 23:49
• It's been ages since Intel's 80x86 line has been competitive in the types of application where an ARM would be used today, but the 8088, 8086, 80286, and 80386, all of which were licensed, were popular with embedded systems. My comment about the Intel was mainly to acknowledge that Intel is popular today despite the fact that it's not licensed like the ARM. – supercat Sep 27 '11 at 3:18
• @supercat: Intel licenses lots of soft IP these days. It also provides design tools and SIP for FPGA design (intel.com/content/www/us/en/fpga/ip-and-design-tools.html) – jbord39 Aug 21 '16 at 19:31
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.

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.

• Related: Multiple RTOS options. – Steve S Jul 14 '11 at 17:30
• Most of your answer is just as applicable to most CPU architectures out there as it is to ARM. Many of them are applicable to 2) as well. The list of architectures supported by Linux is LONG and ARM is only one of them. – Mark Sep 26 '11 at 23:51

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


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.

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.

• Acorn RISC Machine is actually renamed to Advanced RISC Machines (which spells out ARM). Also only the ARM CPU branch of Acorn got independent an is known as Advanced RISC Machines. Acorn continued development of its RISC-OS and I believe it is now know by the latter too. – jippie Nov 15 '12 at 20:36

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.

• Don't ignore small MCU's. ARM is getting a big chunk of that market as well with their Cortex-M series. I'd think twice these days about using a non-ARM 32-bit controller. – Mike DeSimone Jul 14 '11 at 17:56
• Yes, I agree @Mike. ARM is currently attempting to expand into the high power market that intel dominates like servers. They are known for their mid-high range microcontrollerss and low-mid range microprocessors – Kortuk Jul 15 '11 at 0:34
• Intel licenses more IP these days (esp with Altera acquisition). See: intel.com/content/www/us/en/fpga/ip-and-design-tools.html for example. – jbord39 Aug 21 '16 at 19:32

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.

• Note that Microchip's PIC 32 line uses the MIPS core. MIPS is therefore available in small, cheap, self contained, and low power packages too. Further, you can use MPLAB on them, which is something you can't do with any ARM. – Olin Lathrop Jul 14 '11 at 20:02
• The other comment I hear from ASIC designers is that the ARM AHB and APB are difficult to work with (maybe due to separate licensing, or design issues). Whereas the MIPS buses are somehow easier. Meaning: the core is one thing; the peripherals outside the core also need consideration. – Jonathan Cline Jul 22 '11 at 23:11

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

• other answers seem to disagree. – Kortuk Feb 3 '12 at 17:07
• -1 Everthing on Earth has advantages and disadvantages! – RHaguiuda Jun 16 '14 at 13:05