Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Architectures and Processors blog RISC versus CISC Wars in the PostPC Eras - Part 2
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tell us what you think
Tags
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

RISC versus CISC Wars in the PostPC Eras - Part 2

David Patterson
David Patterson
September 11, 2013
3 minute read time.

In my first blog, we examined gave the historical context of the instruction set battles of ARM and x86, covering the RISC-CISC Wars in the PrePC Era and the PC Era. This blog covers Round 3, the PostPC Era [1].

Round 3: RISC vs. CISC in the PostPC Era
The importance of maintaining the sequential programming model combined with the increasingly abundant number of transistors from Moore's Law led, in my view, to wretched excess in computer design. Measured by performance per transistor or by performance per watt, the designs of the late 1990s and early 2000s were some of the least efficient microprocessors ever built. This lavishness was acceptable for PCs, where binary compatibility was paramount and cost and battery life were less important, but performance was delivered more by brute force than by elegance.

However, these excessive designs are not a good match to the smartphones and tablets of the PostPC era. RISC dominates these "Personal Mobile Devices", because

  • It's a new software stack and software distribution is via the "App Store model" or the browser, which lessens the conventional obsession with binary compatibility.
  • RISC designs are more energy efficient.
  • RISC designs are smaller and thus cheaper.

The table below from Microprocessor Report supports these last two claims [2]:


Comparing performance per megahertz, x86 is 4% - 8% faster than ARM or MIPS. More significantly, this table suggests ARM and MIPS have 40% - 50% better energy per MHz and their size is a factor of 3X to 4X smaller than x86.

Independent of these architectural battles, Personal Mobile Devices rely on "Systems on a Chip" to reduce size, improve energy, and to lower costs. If processors are available as IP blocks, any company can create a single SOC rather than use many separate chips on a printed circuit board, as is the case with PCs. Thus far, there is no serious x86 IP competitor to the many fine RISC IP options, so SOCs based on x86 can only come from AMD or Intel.

RISC vs. CISC in the Client and in the Server of the PostPC Era
If Personal Mobile Devices are the clients of the PostPC Era, then Cloud Computing is the server. Virtually all PostPC apps will have one foot in the client and one in the cloud. While RISC has a substantial lead in PMDs, CISC leads in the commodity server market that is the building block of Cloud Computing. 

Interestingly, binary compatibility again plays a small role in Cloud Computing, and cost and energy efficiency again play a much larger role than in PCs. Moreover, when you acquire 100,000 servers at a time to build a Warehouse Scale Computer, custom microprocessors could make sense. RISC competitors would need 64-bit addresses, ECC-protected memory, and good virtual machine support to compete in the Cloud, but the door is not slammed shut as it was in the PC Era.

Conclusion: RISC Reascendancy for Round 3
Note that the volume is on the side of PMDs in the PostPC Era: there will surely be 100 chips built for PMDs for every chip made for Cloud Computing. For 2010, even if you include the whole PC market - which you would expect to fade eventually in the PostPC Era-the RISC chips still outnumber CISC chips by 10:1 to 15:1.

Depending on your perspective, a happy result of the latest round of the RISC-CISC Wars is RISC reascendancy.
_________________________________
[1] "Dawn of a New Day," Ray Ozzie, http://ozzie.net/doc...n-of-a-new-day/, October 28, 2010.
[2] "Broadcom Shows Off New CPU," Linley Gwennap, Microprocessor Report, November 22, 2010.

Anonymous
Parents
  • Alex Solomatnikov
    Alex Solomatnikov over 12 years ago
    Yes, I agree that industry unintentionally experiments with various issues. In 1997 Intel acquired StrongARM from DEC, produced XScaleprocessors with ARM ISA and tried hard to get into cell phone chipset market without success. Now Intel is trying to do the same thing with Atom with x86 ISA, also without success so far. It is hard to come up with more controlled real life experiment than that. So, one can conclude that ISA doesn’t matter and Intel’s failure in cell phone chipset market is not because of ISA – after all they tried ARM first.



    On the other hand, it is not clear why of all RISC ISAs ARM is so dominant in cell phones. Does ARM have any technical advantage over other RISC ISAs MIPS/SPARC/Tensilica? I could not find any numbers or technical papers that show such an advantage. Maybe, SPARC was not suitable for embeddedsystems in the 80s-early 90s because of register windows. MIPS seems to be perfectly suitable and, in fact, is widely used in embedded systems but not in cell phones/smartphones/tablets. Tensilica designed ISA later specifically for embedded systems, provided code density (>20% better than ARM on EEMBC) by variable size 16/24-bit instruction formats (ARM did similar thing with Thumb-2only in 2003), avoided RISC ISA pitfalls such as delay slots and tried hard to penetrate cell phone market - without much success. It is ironic that of all RISC ISAs ARM is actually the least elegant, overloaded with unnecessary CISC-like features such as condition codes, pre/post-increment addressing with shifting/scaling (even x86 addressing modes are simpler).



    So, one can conclude it is not technical merits of ISA that matter but other factors such as being selected by big player, i.e. IBM selecting Intel x86 for IBM PC and Nokia selecting ARM for GSM phone for whatever reason. Of course, afterwards ARM had to execute and deliver “good enough" solutions.



    Of course, in the 80s and early 90s because of limited transistor budgets it probably made sense to put RISC rather than CISC into embedded systems. However, since then it is legacy/software compatibility that kept ARM in the leading position. Software compatibility is less important for cell phones than for PC but nonetheless it is important because of ecosystem of software tools, OSs and difficulty of porting applications to different ISA. Small difference in ISA would not be sufficient for cell phone manufacturers to switch from ARM to another ISA.
    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Comment
  • Alex Solomatnikov
    Alex Solomatnikov over 12 years ago
    Yes, I agree that industry unintentionally experiments with various issues. In 1997 Intel acquired StrongARM from DEC, produced XScaleprocessors with ARM ISA and tried hard to get into cell phone chipset market without success. Now Intel is trying to do the same thing with Atom with x86 ISA, also without success so far. It is hard to come up with more controlled real life experiment than that. So, one can conclude that ISA doesn’t matter and Intel’s failure in cell phone chipset market is not because of ISA – after all they tried ARM first.



    On the other hand, it is not clear why of all RISC ISAs ARM is so dominant in cell phones. Does ARM have any technical advantage over other RISC ISAs MIPS/SPARC/Tensilica? I could not find any numbers or technical papers that show such an advantage. Maybe, SPARC was not suitable for embeddedsystems in the 80s-early 90s because of register windows. MIPS seems to be perfectly suitable and, in fact, is widely used in embedded systems but not in cell phones/smartphones/tablets. Tensilica designed ISA later specifically for embedded systems, provided code density (>20% better than ARM on EEMBC) by variable size 16/24-bit instruction formats (ARM did similar thing with Thumb-2only in 2003), avoided RISC ISA pitfalls such as delay slots and tried hard to penetrate cell phone market - without much success. It is ironic that of all RISC ISAs ARM is actually the least elegant, overloaded with unnecessary CISC-like features such as condition codes, pre/post-increment addressing with shifting/scaling (even x86 addressing modes are simpler).



    So, one can conclude it is not technical merits of ISA that matter but other factors such as being selected by big player, i.e. IBM selecting Intel x86 for IBM PC and Nokia selecting ARM for GSM phone for whatever reason. Of course, afterwards ARM had to execute and deliver “good enough" solutions.



    Of course, in the 80s and early 90s because of limited transistor budgets it probably made sense to put RISC rather than CISC into embedded systems. However, since then it is legacy/software compatibility that kept ARM in the leading position. Software compatibility is less important for cell phones than for PC but nonetheless it is important because of ecosystem of software tools, OSs and difficulty of porting applications to different ISA. Small difference in ISA would not be sufficient for cell phone manufacturers to switch from ARM to another ISA.
    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Children
No Data
Architectures and Processors blog
  • When a barrier does not block: The pitfalls of partial order

    Wathsala Vithanage
    Wathsala Vithanage
    Acquire fences aren’t always enough. See how LDAPR exposed unsafe interleavings and what we did to patch the problem.
    • September 15, 2025
  • Introducing GICv5: Scalable and secure interrupt management for Arm

    Christoffer Dall
    Christoffer Dall
    Introducing Arm GICv5: a scalable, hypervisor-free interrupt controller for modern multi-core systems with improved virtualization and real-time support.
    • April 28, 2025
  • Getting started with AARCHMRS Features.json using Python

    Joh
    Joh
    A high-level introduction to the Arm Architecture Machine Readable Specification (AARCHMRS) Features.json with some examples to interpret and start to work with the available data using Python.
    • April 8, 2025