The Case for Open Instruction Sets
Open ISA Would Enable Free Competition in Processor Design
This article is an extended version of the authors’ original online posting. We have added a counterpoint from ARM (see MPR 8/18/14, “The Case for Licensed Instruction Sets) and the authors’ response to the counterpoint.
Custom systems-on-a-chip (SoCs), where the processors and caches are a small part of the chip, are becoming ubiquitous; it is rare today to find an electronics product at any scale that lacks an on-chip processor. Thus, many more companies are designing chips that include processors than did so in the past. Given that the industry has been revolutionized by open standards and open-source software—with networking protocols like TCP/IP and operating systems (OSs) like Linux—why is one of the most important interfaces proprietary?
ISAs Should Be Free and Open
Although instruction-set architectures (ISAs) may be proprietary for historical or business reasons, there is no good technical reason for the lack of free, open ISAs:
- It’s not an error of omission. Companies with successful ISAs like ARM, IBM, and Intel have patents on quirks of their ISAs, which prevent others from using them without licenses. Negotiations reportedly take 6–24 months and cost $1 million to $10 million, which rules out academia and others with small volumes. An ARM license doesn’t even let you design an ARM core; you just get to use their designs. (Only about 15 big companies have licenses that allow new ARM cores.) Even “OpenPower” is an oxymoron; you must pay IBM to use its ISA. While they’re sound business, licenses stifle competition and innovation by stopping many from designing and sharing their ISA-compatible cores.
- Nor is it because the companies do most of the software development. Despite the value of the software ecosystems that grow around popular ISAs, outsiders build almost all of the software for them.
- Neither do companies exclusively have the experience needed to design a competent ISA. While it’s a lot of work, many today can design ISAs.
- Nor are the most popular ISAs wonderful ISAs. ARM and x86 aren’t considered ISA exemplars.
- Neither can only companies verify ISA compatibility. Open organizations long ago developed mechanisms to ensure compatibility with hardware standards, such as IEEE 754 floating point, Ethernet, and PCI. If not for this capability, open IT standards would be less widespread.
- Finally, proprietary ISAs are not guaranteed to last. If a company dies, it takes its ISAs with it; DEC’s demise also terminated the Alpha and VAX ISAs.
Note that an ISA is really just a specification of an interface, not an implementation. An ISA has at least three possible types of implementations:
1. Private closed source, analogous to Apple iOS.
2. Licensed open source, like Wind River VxWorks.
3. Free open source that users can change and share, like Linux.
Proprietary ISAs in practice allow the first two types of cores, but you need a free, open ISA to enable all three.
We conclude that the industry would benefit from viable freely open ISAs just as it has benefited from free open-source software and interfaces. For example, this approach would enable a real free open market of processor designs, which patents on ISA quirks prevent. Open ISAs could lead to the following:
- Greater innovation via free-market competition from many more designers, including both open and proprietary implementations of the ISA.
- Shared open core designs, which would mean shorter time to market, lower cost from reuse, fewer errors given many more eyeballs, and transparency that would make it hard, for example, for government agencies to add secret trapdoors.
- Processors becoming affordable for more devices, which would help expand the Internet of Things (IoT), with parts costing less than $1.
Managing Evolution of a Free, Open ISA
Successful ISAs can last for decades, so we need a long-term organization to certify implementations and to maintain and evolve a free, open ISA. Inspired by the continuing success of foundations for open software—the Apache Foundation (founded 1999), the Free Software Foundation (1985), and the Open Group (1996)—we propose a nonprofit foundation to certify implementations and to maintain and evolve the ISA. While it would seem problematic to rely on volunteers to play such an important role, the durable success of open standards like TCP/IP (1974) and open-source software like Linux (1991) suggest otherwise. As mentioned above, the computer arithmetic, networking, and I/O-bus communities have already developed mechanisms to certify that hardware implementations are compatible.
Moreover, we believe having the community agree to ISA changes based on technical needs should prove to be at least as graceful an evolution as for proprietary ISAs, where companies must balance the needs of their businesses against the needs of their ISAs. For example, as 32-bit address spaces ran out of gas, both ARM and Intel decided in part for business reasons to radically overhaul their proprietary ISAs, with one being more successful than the other.
Customers who needed 64-bit addresses initially had little choice but to follow: ARMv7 to ARMv8, x86 to Itanium. Customers of x86 were thrown a lifeline from AMD, which has an x86 license and made a more compatible 64-bit x86 on its own—something Intel ultimately had to adopt. It’s unclear what would have happened if AMD had lacked an x86 license. For better or worse, there is no 64-bit version of the 32-bit ARM ISA (v7); customers who want 64-bit addresses must move to the revamped ARMv8.
These examples illustrate that the evolution of a proprietary ISA is decided by the owner, albeit with some input from some important customers. This type of change may even be more disruptive than the evolution of an open ISA, which would be guided by consensus of the whole user community.
RISC Is the Best ISA Style
For an ISA to be embraced by an open-source community, we believe it needs a proven commercial record. The first question, then, is which ISA style has a history of success. There hasn’t been a successful stack ISA in 30 years. Except for parts of the DSP market, VLIWs have failed: all the VLIW startups went belly up, and Itanium was a bust despite billions of dollars invested by HP and Intel. It’s been decades since any new CISC ISA has succeeded. The surviving CISCs translate from complex ISAs to easier-to-execute ISAs, which makes great sense for executing a valuable legacy code base.
A new ISA by definition won’t have any legacy code, so the extra hardware and energy costs of translation are difficult to justify; why not just use an easy-to-execute ISA in the first place? RISC-style load-store ISAs date back at least 50 years to Seymour Cray’s CDC 6600. Whereas x86 won the PC wars, RISC dominates the tablets and smartphones of the post-PC era; in 2013, more than 10 billion ARM chips shipped, compared with 0.3 billion x86 chips. Repeating what we said in 1980, we propose that RISC is the best choice for a (free and open) ISA.
Moreover, a new RISC ISA can improve upon its predecessors by learning from their mistakes:
- Leaving out too much: No load/store byte or load/store half word in the initial Alpha ISA, and no floating-point load/store double in MIPS I.
- Including too much: The shift option for ARM instructions and register windows in SPARC.
- Allowing current microarchitectural designs to affect the ISA: Delayed branch in MIPS and SPARC, and floating-point trap barriers in Alpha.
To match embedded-market needs, RISC architectures even developed solutions to the code-size issue: ARM Thumb and MIPS16 added 16-bit formats to offer code smaller than x86. Thus, we believe there is widespread agreement on the general outline of a good RISC ISA.
Existing ISAs Offer a Good Start
The good news is that there are already at least three free, open RISC ISAs:
- SPARC V8: To its credit, Sun Microsystems made SPARC V8 an IEEE standard in 1994.
- OpenRISC: This Gnu open-source effort started in 2000, with the 64-bit ISA being completed in 2011.
- RISC-V: In 2010, partly inspired by ARM’s IP restrictions as well as the lack of 64-bit addresses and overall baroqueness in ARMv7, we and our graduate students Andrew Waterman and Yunsup Lee developed RISC-V (pronounced “RISC five”) for our research and classes, and we made it BSD open source.
Because it takes years to get the details right—the gestation period for OpenRISC was 11 years and for RISC-V was 4 years—it seems wiser to start with an existing ISA than to form committees and start from scratch. RISC ISAs tend to be similar, so any one might be a good candidate.
Ranking Free, Open RISC ISAs
As mentioned above, ISAs can live for decades, so let’s first project the future IT landscape to see what features might be important to ranking the choices. Three platforms will likely dominate: (1) IoT, which comprises billions of cheap, low-power devices with IP addresses and Internet access, where designers try shave off every penny they can; (2) personal mobile devices, such as smartphones and tablets today; and (3) cloud computing, which is powered by warehouse-scale computers. Although we could have distinct ISAs for each platform, life would be simpler if we could use a single ISA everywhere.
This landscape suggests four key requirements:
1. Base-plus-extension ISA. To improve efficiency and reduce costs, SoCs add custom application-specific coprocessors. To match the needs of SoCs while maintaining a stable software base, a free, open ISA should have: (i) a small core set of instructions that compilers and OSs can depend on, (ii) standard but optional extensions for common ISA additions to help customize the SoC to the application, and (iii) space for entirely new opcodes to invoke the application-specific coprocessors.
2. Compact instruction-set encoding. Smaller code is desirable given the cost sensitivity of IoT and the resulting desire for smaller memory, which improves energy efficiency and reduces cost.
3. Quadruple-precision (QP) as well as SP and DP floating point. Some applications running in the cloud today process such large data sets that they already rely on software libraries for QP arithmetic, which is part of the IEEE 754-2008 floating-point standard.
4. 128-bit addressing as well as 32-bit and 64-bit. The limited memory size of IoT devices means 32-bit addressing will be important for decades to come, while 64-bit addressing is the de facto standard in anything larger. Although cloud computing won’t need 2128 bytes, it’s plausible that within a decade a single warehouse-scale computer might need more than 264 bytes (16 exabytes) to address all of its solid-state nonvolatile storage. As address size is the one ISA mistake from which it is hard to recover, it’s wise to plan for bigger addresses now.
Table 1 scores the three free, open ISAs using these four criteria, plus a listing of critical compiler and OS ports. Unlike the others, RISC-V offers 16-bit versions of popular instructions, which is why “compact code” is checked.
Table 1. Comparison of open ISAs. The newest of the three, RISC-V, provides a broad range of features. The table excludes the new Open Core Foundation, which is planning a 64-bit open core for 2016 based on the Hitachi SH-4 ISA, because of the preliminary nature of this effort. (Source: Waterman, A., et al., The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Version 2.0, EECS Technical Report No. UCB/EECS-2014-54, UC Berkeley, 2014)
RISC-V Meets All Requirements
The industry should rally around a single ISA to test whether a free, open ISA can work. Only RISC-V meets all four requirements, and it is the only one implementing the IEEE 754-2008 floating-point standard. It is also 10 to 20 years younger, so we had the chance to learn from and fix the mistakes of previous RISC ISAs (e.g., both OpenRISC and SPARC offer delayed branches), which is why RISC-V is so simple and clean (see appendix). In addition to the other ISAs missing most requirements, a concern is that the 64-bit-address version of SPARC (V9) is proprietary and that OpenRISC may have lost momentum.
RISC-V has plenty of momentum: Berkeley has built eight silicon implementations and more are in progress, thanks in part to the open-source Chisel, a highly productive hardware design system. Table 2 compares a 32-bit ARM core (Cortex-A5) and a 64-bit RISC-V core (Rocket) built in the same TSMC process (40nm G). Both use single-issue in-order pipelines, yet the RISC-V core uses half the area, consumes half the power, and is faster.
Table 2. RISC-V Rocket versus ARM Cortex-A5. The RISC-V core is faster, is smaller, and uses less power even when both are implemented in the same process (TSMC 40nm G). Neither core has an FPU, nor does the ARM core have the Neon SIMD engine. The Rocket core implements the RV64IMA instructions from the RISC-V ISA. ARM supplied the “no cache” area for Cortex-A5. The Rocket “no cache” area was calculated by subtracting the space for tags and data SRAMs but leaving in the cache controller. (Source: Lee, Y., et al., “A 45nm 1.3GHz 16.7 Double-Precision GFLOPS/W RISC-V Processor with Vector Accelerators,” 40th European Solid-State Circuits Conference, 2014)
Furthermore, despite the relatively low profile of RISC-V until now, a few groups discovered it on their own because of their desire for a free, open ISA, leading to another eight RISC-V SoCs under development:
- India has started an extensive program at IIT-Madras to develop a complete line of processors, ranging from microcontrollers to server/HPC-grade processors. The program began with the IBM POWER ISA, but it switched a year or so later to RISC-V for both technical and licensing reasons. The six distinct Indian processors and associated SoC components are designed to offer viable open-source alternatives to proprietary commercial processors. All implementations will be provided as open source under a patent/royalty-free BSD license in keeping with the RISC-V philosophy.
- The lowRISC project is based in Cambridge (U.K.) and led by one of the founders of Raspberry Pi, which is a popular $35 computer. Its goal is to produce open-source RISC-V-based SoCs, and it has plans for volume silicon manufacturing and low-cost development boards.
- The EDA company Bluespec in the U.S. has customers interested in an open ISA, so it is implementing RISC-V designs in the Bluespec synthesis tool set and has ported and contributed the GDB debugger and Gnu soft-float ABI to the RISC-V effort.
Although it’s hard to set aside our biases, we think the case is clear that RISC-V is technically the best and safest choice for a free, open RISC ISA.
Reflections on the Case for Licensed Instruction Sets
We read an early draft of the companion article from our ARM colleagues Ian Smythe and Ian Ferguson with great interest. We’d first like to say that we admire the success of ARM, and we agree that licensed, proprietary ISAs work well for many companies and markets. It is gratifying to see an architecture inspired in part by our earlier RISC work at Berkeley become so ubiquitous in the modern computing world.
We believe, however, that there are organizations whose volumes are too small to be of commercial interest to companies like ARM, or for whom a license negotiation taking years and millions of dollars is too onerous. There may also be markets, such as cloud computing, in which the companies involved would prefer to participate directly in the evolution of the ISA rather than have to live with the decisions of the ISA owner.
There are points in the companion article with which we certainly agree:
- The importance of building a community around an ISA, which ARM has done very successfully and we hope to emulate.
- The importance of compatibility across implementations—such as thorough validation test suites (which standards bodies must provide), whether they be for networking products, I/O buses, or processors.
There are others with which we respectfully disagree, or perhaps just misunderstand:
- Increasing design-rule complexity makes life more difficult for synthesizable processors. While this situation means that life will be more difficult for teams building high-performance hardened cores for a particular technology as well as for developers of the lower layers of EDA software, synthesizable processors for either proprietary or open ISAs are mostly isolated from these issues. We note that the highest-performance ARM cores are built not by ARM, but by architecture licensees who undertake this difficult technology mapping precisely to provide differentiation. We’re fairly sure those design teams would prefer an easier-to-implement clean-slate ISA that allows them to focus on physical design issues, and they might prefer having the ability to sell their hardened designs to others in order to amortize their development costs.
- The level of royalty is modest and equivalent to those that use open-source processors. If free, open implementations become popular around a free, open ISA, it’s hard to understand how not free is equivalent to free. For many large companies, the cost of the license and time to negotiate it are not problematic, but they can be an issue for other organizations. We do agree that if you have the volumes to amortize the license investment, an additional royalty cost that is reported as a few percent of the chip price seems eminently reasonable given the effort ARM has put into building a very capable and productive ecosystem enabling a huge variety of SoC applications.
- The scrutiny to which the ARM architecture is subjected renders virtually impossible the idea that a government could exert enough influence to insert a backdoor. Trapdoors are not inserted at the ISA level, they are inserted into implementations. Our security colleagues demonstrated how disturbingly easy it is to insert a trapdoor; they added just 12 lines to a 10,000-line synthesizable processor implementation, which allowed a user program to open the trapdoor and escape into supervisor mode. Thus, the tall challenge for proprietary implementations is to discover if an employee in the development group or in the supply chain has been recruited to modify as little as 0.1% of a synthesizable processor to insert a security vulnerability. The “many eyeballs” argument for open implementations makes such an attack more likely to be discovered, and reliance on public-source-management repositories like GitHub makes it more likely for the culprit to be publicly identified and to suffer the consequences.
- The business model of the ISA is not a leading indicator of its long-term success or failure. Many would say that the business models of ARM and Intel are the key to their success. Perhaps the real point was that open ISAs have been tried before, but they never became very popular? If so, we agree. We hypothesize that the major reason may simply be the lack of compelling demand. Our hope is that there is now compelling demand for a free, open ISA through some combination of the switch from microprocessors to SoCs, the fact that cores are a small but ubiquitous fraction of all SoCs, the extreme low cost and low power of IoT, and the desire to find an alternative to x86 for the cloud.
Concluding our reflections, we believe that ARM is a great company that has built a very productive ecosystem for SoC designers. But we also believe that there are significant markets that don’t match ARM’s business model. Hence, we make the case that an open alternative is needed to address those markets.
Open ISAs for All Computing Devices
The case is even clearer for an open ISA than for an open OS, as ISAs change very slowly, whereas algorithmic innovations and new application demands force continual OS evolution. An ISA is also an interface standard (like TCP/IP) and thus is simpler to maintain and evolve than an OS. In Linux, for example, cloud-computing providers must lobby for code changes that may make no sense to developers of more-modest platforms, and thus, these providers may be unable to get their enhancements approved. These discussions are much easier for an ISA, as arguments are about interfaces, not implementations. Moreover, the base-plus-extension nature of RISC-V makes achieving a consensus even quicker, as the optional extensions suggested for cloud computing can be ignored by IoT developers, who will not be burdened with implementing them.
In summary, the evolution and fate of a proprietary ISA depend on the judgment and fortunes of a single company. There is no good technical reason not to have free, open ISAs just as we have free, open networking standards and free, open operating systems. Successful open standards and open-source software can build communities that are just as large as those of proprietary versions, but such has not yet happened for ISAs. Open-standards committees have developed techniques to ensure hardware compatibility, and these techniques should be employed to support a free, open ISA.
Free, open ISAs enable free, open, and shared processor implementations, which could reduce cost and shorten time to market as well as offer transparency that makes it difficult to insert security vulnerabilities. Free, open ISAs would also lead to greater innovation in processor design via real free-market competition, which proprietary ISAs stifle as part of their business model. One initial target for a free, open instruction set is SoCs for IoT, which have extremely low cost and low power demands. RISC-V supports IoT with a simple base ISA and a compact code-size option. Moreover, one RISC-V core similar in makeup to a proprietary ISA core consumed half the area and half the power.
Another target is SoCs for cloud computing, which could benefit from a viable alternative to x86 that supports custom extensions. RISC-V supports cloud computing with optional 128-bit addressing and optional quadruple-precision floating-point instructions, which is part of the 2008-revised IEEE floating-point standard. RISC-V was designed for SoCs, with its base-plus-extension modularity enabling per-SoC customization as well as long-term software compatibility with compilers and OSs. It is technically the best and safest choice for a free, open ISA.
While the first RISC-V beachhead may be IoT or perhaps cloud computing, our goal is grander: just as Linux has become the standard OS for most computing devices, we envision RISC-V becoming the standard ISA for all computing devices.
Krste Asanović is a Professor and Director of the ASPIRE Lab at UC Berkeley. David Patterson is the Pardee Professor of Computer Science at UC Berkeley, leader of the first RISC microprocessor, and a member of the Microprocessor Report editorial board.
 Demerjian, C. (2013). “A Long Look at How ARM Licenses Chips.” semiaccurate.com/2013/08/07/a-long-look-at-how-arm-licenses-chips.
 Patterson, D., and Ditzel, D. (1980). “The Case for the Reduced Instruction Set Computer.” SIGARCH Computer Architecture News 8.6, pp. 25-33. http://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/Arch/RISC-patterson.pdf.
 Bell, G., and Strecker, W. (1976). “Computer structures: What have we learned from the PDP-11.” 3rd Annual Symposium on Computer Architecture, pp. 1-14. http://dl.acm.org/citation.cfm?id=803541.
 Sturton, C.; Hicks, M.; Wagner, D.; and King, S.T. (2011). “Defeating UCI: Building stealthy and malicious hardware.” IEEE Symposium on Security and Privacy, pp. 64-77. http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper005.pdf.
For More Information
For more information on RISC-V, access www.riscv.org. The first RISC-V workshop and boot camp will be held January 14–15, 2015, in Monterey, CA; see www.regonline.com/riscvworkshop for more information. Details on IIT’s RISC-V project are at rise.cse.iitm.ac.in/shakti.html. Information on other RISC-V projects can be found at lowrisc.org and bluespec.com.
Table A1. RISC-V Integer Base Instructions (RV32I/64I/128I) and instruction formats. The base has 40 classic RISC integer instruc¬tions, plus 10 miscellaneous instructions for synchronization, system calls, and counters. All RISC-V implementations must include these base instructions, and we call the 32-bit version RV32I. The 64-bit and 128-bit versions (RV64I and RV128I) expand all the registers to those widths and add 10 instructions for new data transfer and shift instructions of the wider formats. It also shows the optional compressed instruction extension: those 12 instructions with Cx formats, which are 16 bits long. There are other optional instruction extensions defined so far: Multiply-Divide, SP/DP/QP Floating Point, and Atomic.
Table A2. RISC-V Optional Extensions: Multiply-Divide, SP/DP/QP FP, and Atomic. It further demonstrates the base-plus-extension nature of RISC-V, which has optional extensions of: 10 multiply-divide instructions (RV32M); 25 floating-point instructions each for SP, DP, or QP (RV32S, RV32D, RV32Q); and 11 optional atomic instructions (RV32A). Just as when expanding from RV32I to RV64I and RV128I, for each address-size option we need to add a few more instructions for the wider data: 4 wider multiples and divides; 6 moves and converts for floating point; and 11 wider versions of the atomic instructions.