{"id":81378,"date":"2025-03-18T10:00:58","date_gmt":"2025-03-18T14:00:58","guid":{"rendered":"http:\/\/pappp.net\/?guid=ed01a23f2054f16bc879c467a73b5e78"},"modified":"2025-03-18T10:00:58","modified_gmt":"2025-03-18T14:00:58","slug":"checking-in-on-the-isa-wars-and-its-impact-on-cpu-architectures","status":"publish","type":"post","link":"https:\/\/pappp.net\/?p=81378","title":{"rendered":"Checking In On the ISA Wars and Its Impact on CPU Architectures"},"content":{"rendered":"

Source: Hack a Day<\/a><\/p>\n

Article note: This is a nice set of links\/explanation that mostly matches my take on why RISC-V isn't really working out, explained in that critical post-ISA lens that a lot of pieces miss despite it being the status quo for close to 30 years.\nBunch of questionable design decisions in the ISA, PLUS way too much divergence to make the toolchain situation tractable... which is the only way in which ISAs are still relevant.<\/div>
\"\"<\/div>

An Instruction Set Architecture (ISA) defines the software interface through which for example a central processor unit (CPU) is controlled. Unlike early computer systems which didn’t define a standard ISA as such, over time the compatibility and portability benefits of having a standard ISA became obvious. But of course the best part about standards is that there are so many of them, and thus every CPU manufacturer came up with their own.<\/p>\n

Throughout the 1980s and 1990s, the number of mainstream ISAs dropped sharply as the computer industry coalesced around a few major ones in each type of application. Intel’s x86 won out on desktop and smaller servers while ARM proclaimed victory in low-power and portable devices, and for Big Iron you always had IBM’s Power ISA. Since we last covered the ISA Wars<\/a> in 2019, quite a lot of things have changed, including Apple shifting its desktop systems to ARM<\/a> from x86 with Apple Silicon and finally MIPS experiencing an afterlife in  the form of LoongArch.<\/p>\n

Meanwhile, six years after the aforementioned ISA Wars article in which newcomer RISC-V was covered, this ISA seems to have not made the splash some had expected. This raises questions about what we can expect from RISC-V and other ISAs in the future, as well as how relevant having different ISAs is when it comes to aspects like CPU performance and their microarchitecture.<\/p>\n

<\/span><\/p>\n

RISC Everywhere<\/h2>\n

Unlike in the past when CPU microarchitectures were still rather in flux, these days they all seem to coalesce around a similar set of features, including out-of-order execution, prefetching, superscalar parallelism, speculative execution, branch prediction and multi-core designs. Most of the performance these days is gained from addressing specific bottlenecks and optimization for specific usage scenarios, which has resulted in such things like simultaneous multithreading  (SMT) and various pipelining and instruction decoder designs.<\/p>\n

CPUs today are almost all what in the olden days would have been called RISC (reduced instruction set computer) architectures, with a relatively small number of heavily optimized instructions. Using approaches like register renaming, CPUs can handle many simultaneous threads of execution, which for the software side that talks to the ISA is completely invisible. For the software, there is just the one register file, and unless something breaks the illusion, like when speculative execution has a bad day, each thread of execution is only aware of its own context and nothing else.<\/p>\n

So if CPU microarchitectures have pretty much merged at this point, what difference does the ISA make?<\/p>\n

Instruction Set Nitpicking<\/h2>\n

\"\"<\/a>Within the world of ISA flamewars, the battle lines have currently mostly coalesced around topics like the pros and cons of delay slots, as well as those of compressed instructions, and setting status flags versus checking results in a branch. It is incredibly hard to compare ISAs in an apple-vs-apples fashion, as the underlying microarchitecture of a commercially available ARMv8-based CPU will differ from a similar x86_64- or RV64I- or RV64IMAC-based CPU. Here the highly modular nature of RISC-V adds significant complications as well.<\/p>\n

If we look at where RISC-V is being used today in a commercial setting, it is primarily as simple embedded controllers where this modularity is an advantage, and compatibility with the zillion other possible RISC-V extension combinations is of no concern. Here, using RISC-V has an obvious advantage over in-house proprietary ISAs, due to the savings from outsourcing it to an open standard project. This is however also one of the major weaknesses of this ISA, as the lack of a fixed ISA along the pattern of ARMv8 and x86_64 makes tasks like supporting a Linux kernel for it much more complicated than it should be.<\/p>\n

This has led Google to pull initial RISC-V support from Android<\/a> due to the ballooning support complexity. Since every RISC-V-based CPU is only required to support the base integer instruction set, and so many things are left optional, from integer multiplication (M), atomics (A), bit manipulation (B), and beyond, all software targeting RISC-V has to explicitly test that the required instructions and functionality is present, or use a fallback.<\/p>\n

Tempers are also running hot<\/a> when it comes to RISC-V’s lack of integer overflow traps and carry instructions<\/a>. As for whether compressed instructions are a good idea, the ARMv8 camp does not see any need for them, while the RISC-V camp is happy to defend them, and meanwhile x86_64 still happily uses double the number of instruction lengths courtesy of its CISC legacy, which would make x86_64 twice as bad or twice as good as RISC-V depending on who you ask.<\/p>\n

Meanwhile an engineer with strong experience on the ARM side of things wrote a lengthy dissertation<\/a> a while back on the pros and cons of these three ISAs. Their conclusion is that RISC-V is ‘minimalist to a fault’, with overlapping instructions and no condition codes or flags, instead requiring compare-and-branch instructions. This latter point cascades into a number of compromises, which is one of the major reasons why RISC-V is seen as problematic by many.<\/p>\n

In summary, in lieu of clear advantages of RISC-V against fields where other ISAs are already established, its strong points seem to be mostly where its extreme modularity and lack of licensing requirements are seen as convincing arguments, which should not keep anyone from enjoying a good flame war now and then.<\/p>\n

The China Angle<\/h2>\n
\"The<\/a>
The Loongson 3A6000 (LS3A6000) CPU. (Credit: Geekerwan, Wikimedia<\/a>)<\/figcaption><\/figure>\n

Although everywhere that is not China has pretty much coalesced around the three ISAs already described, there are always exceptions. Unlike Russia’s ill-fated very-large-instruction-word Elbrus<\/a> architecture, China’s CPU-related efforts have borne significantly more fruit. Starting with the Loongson<\/a> CPUs, China’s home-grown microprocessor architecture scene began to take on real shape.<\/p>\n

Originally these were MIPS-compatible CPUs. But starting with the 3A5000 in 2021, Chinese CPUs began to use the new LoongArch ISA. Described as being a ‘bit like MIPS or RISC-V’ in the Linux kernel documentation<\/a> on this ISA, it features three variants, ranging from a reduced 32-bit version (LA32R) and standard 32-bit (LA32S) to a 64-bit version (LA64). In the current LS3A6000 CPU there are 16 cores with SMT support. In reviews<\/a> these chips are shown to be rapidly catching up to modern x86_64 CPUs, including when it comes to overclocking<\/a>.<\/p>\n

Of course, these being China-only hardware, few Western reviewers have subjected the LS3A6000, or its upcoming successor the LS3A7000, to an independent test.<\/p>\n

In addition to LoongArch, other Chinese companies are using RISC-V for their own microprocessors, such as SpacemiT<\/a>, an AI-focused company, whose products also include more generic processors. This includes the K1 octa-core CPU which saw use in the MuseBook<\/a> laptop. As with all commercial RISC-V-based cores out today, this is no speed monsters, and even the SiFive Premier P550 SoC gets soundly beaten<\/a> by even a Raspberry Pi 4’s already rather long-in-the-tooth ARM-based SoC.<\/p>\n

Perhaps the most successful use of RISC-V in China are the cores in Espressif’s popular ESP32-C range of MCUs, although here too they are the lower-end designs relative to the Xtensa Lx6 and Lx7 cores that power Espressif’s higher-end MCUs.<\/p>\n

Considering all this, it wouldn’t be surprising if China’s ISA scene outside of embedded will feature mostly LoongArch, a lot of ARM, some x86_64 and a sprinkling of RISC-V to round it all out.<\/p>\n

It’s All About The IP<\/h2>\n

The distinction between ISAs and microarchitecture can be clearly seen by contrasting Apple Silicon with other ARMv8-based CPUs. Although these all support a version of the same ARMv8 ISA, the magic sauce is in the intellectual property<\/a> (IP) blocks that are integrated into the chip. These range from memory controllers, PCIe SerDes blocks, and integrated graphics (iGPU), to encryption and security features. Unless you are an Apple or Intel with your own GPU-solution, you will be licensing the iGPU block along with other IP blocks from IP vendors.<\/p>\n

These IP blocks offer the benefit of being able to use off-the-shelf functionality with known performance characteristics, but they are also where much of the cost of a microprocessor design ends up going. Developing such functionality from scratch can pay for itself if you reuse the same blocks over and over like Apple or Qualcomm do. For a start-up hardware company this is one of the biggest investments, which is why they tend to license a fully manufacturable design from Arm.<\/p>\n

The actual cost of the ISA in terms of licensing is effectively a rounding error, while the benefit of being able to leverage existing software and tooling is the main driver. This is why a new ISA like LoongArch may very well pose a real challenge to established ISAs in the long run, beacause it is being given a chance to develop in a very large market with guaranteed demand.<\/p>\n

Spoiled For Choice<\/h2>\n

Meanwhile, the Power ISA<\/a> is also freely available for anyone to use without licensing costs; the only major requirement is compliance with the Power ISA. The OpenPOWER Foundation is now also part of the Linux Foundation<\/a>, with a range of IBM Power cores open sourced. These include the A2O core<\/a> that’s based on the A2I core which powered the XBox 360 and Playstation 3’s Cell processor, as well as the Microwatt reference design<\/a> that’s based on the much newer Power ISA 3.0.<\/p>\n

Whatever your fancy is, and regardless of whether you’re just tinkering on a hobby or commercial project, it would seem that there is plenty of diversity in the ISA space to go around. Although it’s only human to pick a favorite and favor it, there’s something to be said for each ISA. Whether it’s a better teaching tool, more suitable for highly customized embedded designs, or simply because it runs decades worth of software without fuss, they all have their place.<\/p>","protected":false},"excerpt":{"rendered":"

An Instruction Set Architecture (ISA) defines the software interface through which for example a cen…<\/p>\n

Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[226],"tags":[],"class_list":["post-81378","post","type-post","status-publish","format-standard","hentry","category-news-2"],"_links":{"self":[{"href":"https:\/\/pappp.net\/index.php?rest_route=\/wp\/v2\/posts\/81378","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pappp.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pappp.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pappp.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pappp.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=81378"}],"version-history":[{"count":0,"href":"https:\/\/pappp.net\/index.php?rest_route=\/wp\/v2\/posts\/81378\/revisions"}],"wp:attachment":[{"href":"https:\/\/pappp.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=81378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pappp.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=81378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pappp.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=81378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}