RISC-V is succeeding
semiengineering.com
semiengineering.com
If you make your own CPU
- With ARM, You have to pay ARM for ISA license (after a several months long negotiation), and you cannot license your CPU design to anyone, as ARM has the exclusive right to do that with their designs.
- With RISC-V, you get a free ISA license, and you can license your CPU design to others.
If you do not make your own CPU
- With ARM, you can (after a several months long negotiation) license one of the few designs ARM has available. There's no other vendors that can offer you ARM CPU designs.
- With RISC-V, right now, you can license any among hundreds of options available, from tens of vendors. The licensing process is usually very short and straightforward. Alternatively, there are some open hardware designs. You can get commercial support for some of them.
Frankly, unless ARM does radically change their business model, I do not expect them to survive.
Anyway, that's all well good, but - does anyone end up making decent RISC-V processors that could replace a desktop CPU, or a RPi CPU, or something weaker but not in a small niche? Or is this still a vision for the future?
As of November, a large number of extensions got ratified, including the vector extension, cryptography acceleration, hypervisor support and other important features.
RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density.
However, test chips with the first designs implementing all of that will take time, even assuming they were tapped out right then, after confirming no last minute changes.
High performance cores depend on these extensions, so we'll begin to see them soon. We know multiple such efforts exist.
Tenstorrent has one such project, led by Jim Keller.
>Their (ARM) business model was to be sold to NVIDIA, but that didn't work out.
They intend to go public now. I recommend against buying those shares, as I do not expect ARM to turn around.
This has historically been a problem with RISC-V and it’s not really something you’ve backed up as being improved.
I am not sure how to parse the «simpler, i.e. better» part; simplicity vs betterness is orthogonal at best and is contradictory at worst.
Very few people write meticulously handcrafted, highly optimised code for any ISA today, and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Simplicity of the ISA does not immediately translate into faster or more optimised code.
Moreover, creating a highly efficient optimiser is no easy feat as it depends on a large variety of factors and the in-depth knowledge of a specific CPU incarnation: the knowledge of each instruction's timing, instruction interdependencies (i.e. the most optimal instruction sequence that does not stall the pipeline or maximises the ALU/whatever utilisation etc etc), L1 I and D cache line sizes, the knowledge of a particular CPU model / generation… – and that is just a beginning. There is a good reason why Intel, AMD, IBM, ARM et al publish hefty optimisation guidelines / documents for each generation of their CPU's with the compiler writers in mind: the same sequence of instructions issued for the CPU model 123 might be less (or more) efficient than in the next CPU model 456 and vice versa; moreover (e.g. specifically for Intel vs AMD), a sequence of instructions optimised for a particular Intel generation might underperform for an equivalent AMD model or vice versa. Same is likely to be true for different RISC-V core designs from different RISC-V vendors. This is the reason why -mcpu=XXX and -mtune=YYY exist in GCC and clang/LLVM: efficient low-level code optimisation is a tricky business and depends on a large number of compounding factors.
It remains to be seen how the optimisation will be tackled in the RISC-V case with its potpourri of optional ISA extensions and also with the instruction fusion. Given that a random concrete RISC-V implementation can be a combination of the base ISA + a random permutation of any RISC-V extensions (in the worst case scenario), emitting the code that will run equally efficient across N different RISC-V core designs appears to be problematic. Instruction fusion can pose another challenge as a fused macro-instruction may or may not run as efficiently on a RISC-V instance that does not fuse them. There is no guarantee that the compiler generated / optimised code will be equally highly performant across different implementations even for the same set of ISA extensions.
Itanium aka the Itanic demonstrated this is not the case.
This is not correct and is a known weakness of RISC-V at the moment. The ARM toolchains are really good and have decades of improvements in them. This is a big issue for those who need to buy ROM in volume.
Better tools are coming online though. For example:
https://blog.segger.com/code-size-closing-the-gap-between-ri...
"One of the issues faced by RISC-V developers is that the code density of the RISC-V instruction set for deeply embedded processors does not match that of Cortex-M with existing tools."
What they plan to do with them is unknown, but Apple has the cash flow to try a lot of things.
I would expect them to quickly adopt it for embedded applications, and experiment with making their own high performance design, including porting MacOS and Rosetta Stone. They can afford to do this much, regardless of whether they end up moving their main CPUs to RISC-V or not.
Trust modules, device controllers, smart adapter cables etc.
I might be making this up (I can't remember the company) but I'm pretty sure at least one chip designer has moved from risc-v to arm. It's not clearcut.
On the other hand there is a vast market for low-end CPUs that have specializations to be disk controllers and things like that. If the ISA and all the IP required to make specialized devices is free and particularly if there is a culture in which it is easy to learn how to do that then RISC-V will have a special place.
My next spatial computing project is going to be RP 2040 based mostly because I have the parts in stock (other projects are blocked because of supply chain issues) but I am really an AVR8 fanatic and the only path forward I see to higher performance AVR8 systems is a soft core running on an FPGA where very hard tasks (vision? comms?) get offloaded to the FPGA and that can be a very appealing architecture where somebody might prefer RISC-V particularly if the tooling and accelerator integration are there.)
It might also be successful, even in that segment. The RISC-V ISA was specifically designed to scale up (e.g. to OOO and vector processors) while still being very simple, especially at the low-end - a basic RV32E is really comparable in complexity with many real-world 8- and 16-bit chips.
But, the similarly minimal Arm Cortex M0 is, drumroll, 12k gates.
Not saying this means Arm is better than RISC-V, such a small difference can probably be explained by some microarchitectural feature or lack of it. Just that you can scale down Arm as well.
But yes, I can see tiny chips like these putting a squeeze on 8 and 16 bit microcontrollers.
That's not the impression I got, when I studied the specification.
Do you care to elaborate?
I remember reading that ex-ARM employee's take back then, when it was discussed here[0]. It was based in a pre-standard version of the ISA which was already old at that point in time, and also ignored the rationale behind many of the decisions it criticized.
By objective metrics (simplicity of instruction set, features available, code density, absence of µarch assumptions), I find RISC-V to be the best general purpose ISA available at the present time.
If the macro fusions don't work for example that's a pretty dramatic blow against RISC-V compared to aarch64. Similarly code density is a tradeoff because riscv's simplicity means more instructions in the first place i.e. requires actual battle testing first.
He said they were talking about open-sourcing the CPU block. If they did (the CPU isn't their core business), we could see lots of RISC-V competition popping up. The age of CPUs being commodity items seems to be approaching.
Either way I don't think anyone is seriously arguing you can't make a high-performance RISC-V process, but the thing is that scaling from (say) fast at memory and basic integer operations all the way up to all the sometimes wacky shit people want from their desktop machines will probably not be easy. It took Apple decades to do it with an ISA they helped design themselves.
They didn’t mention how many branch units they have, but the ALU count is identical to X1.
They have half the SIMD units, but each unit is twice the width which increases instruction density on high performance workloads.
I also think the high performance here is a relative term to their small core.
Whether you are designing a server chip or machine learning powerhouse it is all about having lots of cores. To get more cores you need smaller cores and RISC-V has demonstrated they can make small cores of half the size of an ARM core with similar performance.
RISC-V simplicity really starts paying off once you go very small.
The only really janky part is the fusion of more than 3 instructions. Now that is insane. However, it is like energy storage for renewables. Once you have an electric grid that can store days worth of energy that's actually extremely amazing. The old way of doing things will be viewed as something cavemen or barbarians did. If macro op fusion scales beyond 3 instructions then RISC V will easily beat other architectures because 2 is the limit for every other architecture.
A note for those not following: RISC-V as in RV64GC. x86 as in 32bit x86.
64bit x86 aka x86-64 aka amd64 is dramatically worse in code density.
Building a desktop system with a PCIe graphics card would be easier.
I believe the team behind LibreSOC is also working on a 3D processor, but I don't know how far along they are.
However, if a vendor instead ships a decent framebuffer and high-performance vector unit, I think LLVMpipe would not be a problem for most RPi-equivalent use cases, either light desktop use or server use (especially the latter!)
I kind of agree, but it’s not straightforward. ARM’s growth wasn’t so much a hockey stick as a more continuous curve with a small exponent. Yes, they only started in 1990, but that was itself a reboot/restart after acorn’s 12 years of effort. And they were scrambling hard for every deal for at least another 15 years.
The environment in which RISC-V emerged is different, of course, but many of the dynamics are still the same. Car companies were still using 16 and even 8 bit devices into the 21st century.
Secondly, ARM has a large arsenal of patents that go along with the license, and they continue to add to the load.
I bear ARM no ill will but I also want RISC-V to supplant them. I just don’t think it’s automatic.
Of course RISC might push them to make their licensing mechanism to be more flexible if they start considering RISC an a real threat to them (I don’t think this is very likely to happen in the near future, though)
I'm afraid they have seen RISC-V as a threat for a while now. It has already been years since their first FUD campaign.
>if ARM started allowing everyone to use their IP for free you would expect them to survive?
That's not how I see ARM surviving.
One way ARM could survive is by doing what the MIPS owners did: Abandon the ISA, move to RISC-V, use your extensive expertise to make competitive cores, and your clout in the market to sell them to your pre-existing clients.
They could totally pull it off, but it would honestly surprise me if they did so, considering how poorly they've dealt with RISC-V so far.
Even if that’s their best bet, long term, I don’t see why they would have to start doing that right now. Why would they leave their castle with its golden egg-laying goose, only because they know it won’t live for X more years?
Timing such transitions is always difficult (you can’t wait until your goose is dead), but I think they’re better of waiting at least a few more years.
The MIPS owners were in a different situation, weren’t they? Their goose already was dying or even dead.
Me neither, but spreading FUD about RISC-V as they've been doing doesn't help their credibility should they take the MIPS path.
ARM's vast experience brings the quality you've come to expect to the RISC-V world. Want to lower TCO and level up your designs, while leveraging existing experience, but worried about low quality IP polluting your tech? Fear not. etc...
You can probably let an AI spew this stuff by now. Training data is easy to find.
Got a good chuckle from that, I did! :D
Alas, that would probably have worked better 2+ years ago, there is a lot of movement now.
It seems like Intel has realized this. They tried to buy Sifive, but have now themselves joined as a major RiscV International sponsor and are investing heavily in the ecosystem.
Of course there is a downside there too, because it accelerates a software and hardware ecosystem transition to a different architecture that can enable other players. We'll see how it plays out
One of the reasons Intel is spending money on RISC-V could be that they want to undercut Arm, as the latter are now beginning to be competitive in Intel's X86 world. RISC-V is going to succeed at all as an ISA, it is going to hurt Arm before Intel.
MIPS was pretty dead when they abandoned it, ARM is still alive and well.
ARM could survive by making the ISA free and competing by having the best ARM core designers and designs, and/or by having proprietary addons for media handling/decoding.
The trend with RISC-V suggests that ISAs are going to be commoditized and the real value will be in the implementations themselves.
It is not that difficult to re-target a micro-architecture (what you call implementation) to a new ISA, especially if the ISAs relatively close, as most modern ISAs are. RISC-V and Arm ISAs are an example where that should be especially easy.
Why pay for ARM if you can retarget to RISC-V and still retain most of the benefits of your designs.
Right now, the Arm ISA has much better micro-architectures than RISC-V, why bother with RISC-V? I think this will change over the next 5 years. One of the ways to change this could be Arm selling RISC-V implementations.
Of course there are also dangers in RISC-V: one is that we will get too many RISC-V versions, so no stable software ecosystem emerges for any single one of them. Adapting Linux, GCC and so on to your specific version of RISC-V (or any processor really) is rather expensive.
It is the fundamental basic business ideas that they have it all wrong. Which is why every time these discussions came up they are non-productive. It is no different to saying Linux would take over desktop in the 90s because it is free. We are in 20s and coming up 30s. It is still not happening.
But at least ( or hopefully ) we have passed stage where RISC-V is fundamentally better ISA than ARM. And talk about the business aspect of it.
Edit: Ok I was wrong, the ISA debate is near the bottom of the page. I didn't invent the term "Riscy Silver Bullet" for no reason :).
Completely agree.
The desktop? Maybe not. But Linux has done well with laptops in recent years (Chromebooks). Definitely not "taken over", but 30 million units a year is nothing to sneeze at either.
Irrelevant question that no one anywhere has any obligation to care about.
But ARM probably cares about ARM's survival so it is relevant to the discussion about what future decisions ARM might make.
I literally quoted a question that asks "you expect", and what I am pointing out, not declaring but observing, it's already a fact regardless if I say it, that neither you or I nor anyone else has any obligation to expect anything.
It doesn't even matter if we do expect something. Even if you were some kind of Arm fan like being a fan of a sneaker brand or a celebrity, your good wishes still don't change anything.
"you expect" is just irrelevant in this question. Arm can adapt to the new environment or not. The environment is changing and it doesn't matter if anyone likes it or not.
And the nature of the change, people giving away something that someone else used to be able to charge rent for, is not unfair or unethical or immoral in anyway, nor is it any kind of net loss for society as a whole, so there is no argument for doing something to artificially protect Arm's business model.
Steve used to sell cakes. Sally gave everyone her recipe for cake and now fewer people buy Steve's cakes. So what?
Do you mean to say that Sally should not be able to give away her own cake recipe? Steve doesn't like it because he had a good gig going for a while there, but so what? The environment Steve was operating in changed, and his business model no longer works. And while you could sorta-kinda say it's Sally's fault, you can't say she did anything wrong either legally or morally or in a holistic sense for everyone as a whole, and so there is nothing anyone else should do about it. Steve had no special right to his cakes being purchased. He has the right to offer them, but no one is obligated to buy them, and no one is obligated to care if he fails to sell enough to live well on.
I don't expect anything related to Arm, and neither can anyone else. It's just a totally irrelevant question.
Longterm I’m afraid that a completely open ISA might result in a less competitive market as long the cost of developing competitive cores is high enough. All top players could just start behaving like Apple and just keep their cpus for their own products/cloud services instead of selling them at commodity prices and losing a competitive advantage. So having a ‘neutral’ player like ARM might still be preferable.
- Arm has no IP that can’t be quickly replicated by other firms (for very little money).
- That the quality of designs from other firms will be better than those from Arm (or for the architecture licensees their own).
- The really big Arm licensees would see a commercial advantage to switching.
Intel threw billions at the smartphone market and still lost against Arm. Today there are zero RISC-V smartphone designs. That may change but probably largely because of the Arm China and Nvidia missteps.
I expect (and look forward to) RISC-V establishing a presence in the market but this sort of commentary does the ISA no favours.
Edit: I see elsewhere you think they should abandon the Arm ISA in favour of RISC-V! really not sure about that ..
2) Network effect favoured ARM.
https://riscv.org/blog/2020/11/13-year-old-nicholas-sharkey-...
We've got kids designing their own cores. That was a bar that previously was out of reach to anybody without a nine-figure engineering payroll. That's amazing.
RISCV does make it a bit easier and gives you a clean ISA but it hasn't really had that much of an influence due to its own design i.e. it's caused people to herd around it so there's lots of tutorials and work to borrow floating around.
SPARC was able to run Linux and Solaris, and used by Sun in their servers that powered much of the commercial internet in late 90s and early 2000s (before x86 Linux took over).
There have been a few others since then. So relatively sophisticated open source cores for study and modification have been around for many years by now.
It looks to me like the difference with RISC-V is that a larger community has formed around it due to smart organisation and the timing being right, rather than availability.
Dumb cores are a commodity now, which progressed in horsepower from their ca. 60 years old ancestors. I.e. the core is hardly innovative, so what is so amazing about it, technically?
This toolchain enables going from knowing nothing to a core in one class. One doesn't even need to enroll in the class to follow along.
See: https://ocw.mit.edu/courses/electrical-engineering-and-compu...
From article: “The open-source community developed key tools that are crucial to make RISC-V-based processors ubiquitous, such as chip technology process design kits, design verification suites, implementation tools, and more”
Closed source tooling was available and “smart”, but licensing, cost, and inflexibility were significant roadblocks. Disclaimer: I don’t work in the industry.
Things like: is it enough for one to make any core or does one have to make the "best" core? If it just has to exist that was pretty much always possible. Definitely not the lowest friction way to go. But possible.
For example here is basic MIPS core originally written in 2003, from chapter 1 of a common VLSI textbook: http://pages.hmc.edu/harris/cmosvlsi/4e/code.html
It's just over 400 lines of verilog and super easy to follow. The tooling changes that happened in the 90s made that possible.
I experimented making cores that were taped-out in my University, as an undergraduate, in the late 90s. It didn't cost my University even close to 9 figures. It was definitely a lot harder than now but the designs were also a lot more modest. Things, essentially untrained, students can do now would've been unthinkable then.
I also trust the ARM ISA designers more than the RISC-V ones, but I don't know enough that you should trust me.
I was going to use that exact wording in a different comment but decided against it, spooky
I mean there was clearly a lot of analysis put into aarch64 - which probably involved Apple etc - but I've seen comments previously saying they obviously got it wrong because [insert some headline design decision].
They might have got it wrong but they're definitely not amateurs at this and you can't prove anything with a one line comment.
I feel ARM could go the Docker way, who faced a similar foe in the stakeholders seeking to commoditize their core business... ruthlessly stomped on them, creating k8s, runc, registries, microvms, serverless, and what-not. Despite Docker having stellar engs working for them (and in some cases, better tech: Swarm, for instance), there's nothing they could do.
The Tencent and Apple of the world are...Tencent and Apple.
If Amazon say decided to throw billions at developing a Graviton 4 using RISC-V...they really couldn't leverage much of their previous Graviton development work. They also wouldn't have a deep bench of low level RISC-V wunderkind to bring on board to leverage the new platform. It's a chicken and egg problem.
Why would Amazon then want to pay to bootstrap a whole RISC-V market? That's a lot of CapEx without a clear potential for returns. You'll note they did develop Graviton using the ARM ISA so they didn't have to create from whole cloth a "Graviton" market.
Amazon made the same decision as PC makers in the 80s. They consolidated around the IBM clone architecture to take advantage of the rest of the market, especially Microsoft and IBM, supporting the IBM clone market. Commodore, Atari, and Apple all had to fight uphill against IBM clone market.
I haven't seen any technical advantage of RISC-V over ARM that would suggest it's worth pouring billions of development dollars into. It might make sense for Western Digital for drive controllers but not phone, tablet, PC, or server makers.
RISC-V has geopolitical advantage however in that it's not controlled by US/UK.
I can see why Amazon wouldn't pay to bootstrap that, but I can see why Tencent/Huawai/Alibaba would try to.
Now, if someone would create a RISC-V core competitive with the Arm server cores, and an ecosystem of RISC-V compatible peripherals (well, not compatible in the sense that some random peripheral would need to care about the ISA, but that Arm might not want to licenses their peripherals to a RISC-V based project?) shows up, I'm sure Amazon could do roughly the same with a hypothetical RISC-V Graviton. But if you're talking about designing a RISC-V core from scratch, that's a whole different ballgame.
This is my point. Amazon using ARM lets them tap into the huge ARM ecosystem with minimal investment on their part. The cores they're using have known qualities and meet whatever performance targets they want.
At this point RISC-V doesn't have that same ecosystem. It doesn't even have extant high performance cores someone can just order. Building momentum is expensive. If selling that ecosystem isn't your main business it's probably not worth investing millions or billions to develop it.
You're not wrong in your assessment. However you're looking at it as it is right now, as opposed to where it's headed for in the future and what it could ultimately become. While CG and computer hardware are very different fields, the effects of communal knowledge sharing are very similar and very powerful. When bored high schoolers and broke college kids (and curious adults) can tinker with the tech, they enter the industry with that much more experience and/or have another avenue for career transition. And that is far more valuable than the mild (and sometimes nonexistent) conveniences of ARM over RISC-V.
In the first case anyone with the right skills can do it. In the second you need access to lots of specialist tools / proprietary industry knowledge.
If RISC-V 'wins' in application processors it will be because an Intel or a Qualcomm invests (probably) hundreds of millions in building a team that works on a multi year project. It definitely won't be bored high schoolers.
https://info.efabless.com/press-release-efabless-launches-ch...
> In the first case anyone with the right skills can do it. In the second you need access to lots of specialist tools / proprietary industry knowledge.
In the first case, it used to require specialist tools like the Autodesk suite, and people had to have access to that software to develop the right skills and acquire the industry knowledge.
I don't think RISC-V "winning" is the right way of measuring success. Whether or not it becomes the dominant ISA for everything is irrelevant. It serves an important role in our market and it doesn't need the guys at Qualcomm and Intel to use it to make it successful. Either way Intel is investing big money into RISC-V: https://www.zdnet.com/article/intel-invests-in-open-source-r...
Also, careful what you say about high schoolers: https://riscv.org/blog/2020/11/13-year-old-nicholas-sharkey-...
RISC-V for hobbyist like me is just WAY WAY easier to deal with. There is a great consistency between RISC-V 32-bit and 64-bit which ARM lacks. There is just one compressed ISA and it maps to the regular one in straight away manner. Register naming is more sensible and consistent.
ARM instructions with their complex addressing modes are not easy to read. ARM vector instructions makes your head explode trying to keep all the details in your head at the same time. RISC-V vector instructions are just way easier to grasp.
In many ways it reminds me of the documentation situation with Python vs Julia. Python has more documentation for sure, but a big problem with that is all the stuff that is outdated irrelevant, combined with the difference between Python 2.x and Python 3.x although that has gotten easier in recent years.
New technologies will always have less documentation but they often benefit from not having lots of legacy which complicates understanding.
At least ARM is easier than x86, but that is a pretty low bar.
Suppose you just want a soft core for a one-off FPGA project. RISC-V is a no-brainer if you need to run complex stuff like a Linux kernel. There's myriad of projects to pick from on GitHub. Try them all, pick the one you prefer.
The barrier to entry is so much reduced that you can use RISC-V "by accident" without having considered it in advance, as part of a normal engineering process in companies of any size, vs months-long waits for IP, after deciding it was worth obtaining.
Survive what? I don't see RISC-V disrupting much of ARM's bigger-named business (eg, phones, with some inroads into other things like Apple Silicon & laptops). Maybe Amazon pivots into RISC-V for the next Graviton? But that also seems unlikely unless someone with very deep pockets invests in making an actually competitive RISC-V CPU core at the mid/high end.
ARM's low-end market seems likely to be taken over by RISC-V. So like the Cortex M series days seem numbered without a change in the business model. But that seems like about it.
Go back a decade or so: how many people thought that ARM could compete against Intel/AMD?
ARM has so far, outside of Apple and very limited cloud experiements (and some very badly received laptop experiments), not really put a dent in Intel/AMD's markets. But all of this was fueled by the once-in-a-generation explosion that gave ARM untold increases in adoption "for free". RISC-V has seemingly nothing similar, and RISC-V itself certainly isn't manufacturing any such radical shift.
It's a matter of time other shares will be eaten when x86 is having hard time innovating over its decades old design.
More battery time for consumers laptop and less electricity bill for cloud vendors are something very attractive.
Yes, obviously, which I mentioned repeatedly. For ARM to be successful outside of embedded it took an entirely new category of device to appear. What's RISC-V's entirely new category of device where it happens to be uniquely positioned?
> It's a matter of time other shares will be eaten when x86 is having hard time innovating over its decades old design.
Based off of what? The only ARM CPU that isn't thoroughly outclassed by AMD & Intel's x86 CPUs is Apple's, and Apple sure isn't licensing that to anyone. And so far every time ARM has tried to enter the domain of x86 it's been either absolutely embarrassingly bad (laptops) or mediocre at best and only for the very latest generation at that (servers)
> less electricity bill for cloud vendors
ARM server CPUs have the ~same 250W TDPs of Intel & AMD server CPUs. There's no power savings to be had here.
Chromebooks on ARM have already been out for a year. Windows RT for ARM was coming out later in the year. Smart phones are clearly all going ARM. The 64 bit ARM spec was out and people were excited about it.
I think it was a lot clearer that ARM was going to succeed x86, as compared to looking forwards now as to where RISCV will beat ARM.
I do suspect the microcontroller ecosystem will have lots of RISC-V. But it seems a lot less clear that it will succeed ARM in the mobile/laptop/desktop/server markets. I personally do not think that’ll likely happen any time soon.
Hello, that would be me? :)
A decade ago was 2011 / 2012. Not a lot ( if not zero ). Even Anand from Anandtech was still cheering on Intel because of Intel's foundry leadership.
Wrote it on Anandtech and AppleInsider ( probably on HN with my old account as well ) the moment Intel decide not to make chips for iPhone or Fab Chips for iPhone in 2011. That was before Intel announced their Customer Foundry. They later went to do a JV with a Chinese company which later become Spreadtrum now known as Unisoc.
The whole reason why Arm competed against Intel and AMD wasn't because of ARM the ISA. It was the business interest and Foundry model. On a projected annual 1.5B Smartphone shipment by 2020 ( Which turns out to be a little too optimistic ), and 150M PC shipment by 2020 and continue to trend downwards. ( A little too pessimistic ) Even had TSMC not taken over the leading edge crown or stayed one node behind Intel the market today would still have been the same. The smartphone market was far bigger than the PC. This actually ties to why people were dismissing moore's law in the late 00s and early 10s. And it was the economy scales that wins.
What turns out to be wrong though was Tablet didn't take over PC. We are not in a Post-PC world. E-Sport (x86) picks up and PC as a Gaming platform is bigger than anyone could imagine. PS4 would move to x86 ( I dont think rumours of PS4 on AMD x86 even began til early 2012, and only partly confirmed by 2013 ) GPU is no longer a Gaming niche but a fundamental in Data Science. The hype of so called Cloud where everyone laughed at or sceptical of ( that is including me ) turns out to be multiple order of magnitude bigger as well. x86 ( Intel / AMD ) thrives because of that.
There is a huge discussion about peripherals and IP. You can buy peripherals for ARM all day long, they’ll work from one chip to another for the most part. Once everyone can “make their own CPU”, expect fragmentation in the peripheral interfaces.
I think low end cortex A and R are where V will shine first. Something like a CISCO IP phone, not an iPhone.
Doesn't that inevitably set up a classic Innovator's Dilemma?
Kinda like how Intel just never cared about going after embedded, and they're not exactly struggling as a result of that. With the big asterisk of smartphones where scaling up proved a quicker path to shipping than scaling down, at which point inertia took over, but for that to repeat would require a currently unknown new product category.
> With ARM, You have to pay ARM for ISA license
This is only true for some definitions of ARM. See for example:
https://en.wikipedia.org/wiki/Amber_(processor) "The Amber core is fully compatible with the ARMv2a instruction set and is thus supported by the GNU toolchain. This older version of the ARM instruction set is supported because it is not covered by patents, and so can be implemented with no license from ARM Holdings"
> Frankly, unless ARM does radically change their business model, I do not expect them to survive.
Looks like someone is having similar thoughts inside ARM. https://hackaday.com/2018/10/02/free-arm-cores-for-xilinx-fp...
There are other efforts too.
I don't think licensing fees to ARM are a problem per se, it's the "frictional costs" that it introduces. My understanding is that the Raspberry Pi developed their RP2040 because ARM had a reasonable package available for its low-end Cortex-M processors, which doesn't apply to their higher-end Cortex ones.
RISC-V doesn't even have these restrictions. Even extremely small outfits can play around with RISC-V designs. Most of them won't go very far, but with enough lottery tickets, one of them is bound to draw the winning numbers.
Sure there are considerable obstacles. I toy with microcontrollers. For hobbyists like me, ARM processors are still the most sensible choice. I'm not expecting any shift from that for at least five years. But who knows after that? Anything can happen.
Free stuff does fail for all kinds of reasons.
By virtue of being open source, RISC-V won't vanish, no matter how many companies choose to adopt it as their ISA and fail.
Seems like, given enough time, one of those companies will just not die, and end up getting big.
But if you take the set of people who have written free operating systems, there's at least one big winner.
So I'll fall back on the "optionality" argument. Vendors, particularly small vendors, can experiment with RISC-V either free, or very cheaply more so than they can with ARM. Right there, RISC-V opens up a segment that didn't exist before. They'll be more experimentation. When your downsides are limited, but your upside is potentially huge, that's what I mean by "optionality". This is a powerful driver of success.
Naturally, any individual endeavour can fail, but collectively, there's going to be some huge winners.
My prediction is that RISC-V will open up some new category of computing. I can't tell you what it is, who will do it, or when they'll do it, because I don't know. My point is not so much that I can predict what it will be, but merely that there are forces in favour of RISC-V.
I am not, however, predicting the imminent demise of ARM.
I think also that a lot of commentators are viewing things through the lens of what we understand and the received wisdom today. Even - or maybe especially - experts tend to be hemmed in by what is "obvious".
RISC-V is like a genie that's been let out of the bottle. You can't put it back in.
[1] https://lowrisc.org/docs/memo-2014-001-tagged-memory-and-min...
Software is less affected by these issues because it's inherently more flexible. If I install some wonky experimental Linux feature, it doesn't really matter and I can just revert. Different story when this is baked into hardware. The startup costs for independents to contribute to a software only ecosystem is also much lower. How many organisations have the talent to contribute to RISC-V, but wouldn't be able to afford purchasing a license?
Didn't mean to sound so negative but I worry in the hardware space that the advantages of such an open design are not as great.
The big plus of RISC-V is allowing those who accept the risks and cost to experiment and develop new specialized components. Arm won't let you.
It's kind of funny way of looking at the core part of the ARM ecosystem while forgetting how much outside of the CPU is non-standard, undefined. None of the ARM devices share bootloader, device enumeration, and a plethora of things needed for an open, non-fragmented OS/Software ecosystem like how PC does.
Maybe you can run parts of the same ARM machine code on most devices, but it's not terribly portable to be honest, it has to be very generic. For example, Android devices end up in a pile of trash because you can't just upgrade the kernel to the latest version on a 1, 5, 10 year old smartphone without losing functionality or being stuck at step 1 for the lack of tools from broken forum links and shady fileshares. So much for software flexibility...
I do worry though that the RISC-V ecosystem could be really torn in two by a big player (Intel?) who adds proprietary extensions and associated software.
Or are ARM devices so crazily fragmented that I need to custom compile for each and every device in existence?
With RISC-V you could end up with LESS fragmentation, no more. A lot more of the specialized chips can start using RISC-V with particular extensions rather than inventing their own ISA.
That has benefits in that one can reuse more tools and code.
I don't see a reason why RISC-V for desktop systems or high-end smart phones should get any more fragmented than ARM. There is already a standard set of extensions RV32G for these kinds of hardware.
And at least RISC-V has been designed from scratch to handle fragmentation. The base standard gives developers a way to check what extensions are supported in code. It also allows operating systems to include code to simulate unsupported instructions.
RISC-V is prepared for fragmentation in a way that ARM isn't. It is different to design for that possibility and find ways to deal with it as opposed to design around that idea that through strict rules one would avoid fragmentation ever happening.
I guess it's nice to have a free CPU core but at the end of the day you want USB, external RAM, a bus to connect all these things and so on.
Maybe we will have free implementations of those at some point but it probably won't be from the current crop of chip designers - there have probably never been more ungrateful, non-reciprocal users of free software.
When you are talking chips with peripherals and packages and memory configs, it gets a little more muddy.
When the conversation moves from academic to trying to buy a chip and ship a product.
I am aware of a popular chip vendor next year making a three core chip. Core0 the fastest and primary is a RISCV, it will be flanked by two smaller and weaker ARM cortex m0 or m4s.
They’re doing that because they have peripherals established for the ARM and almost none for the RISCV.
It's unlike Linux in so many ways, licensing being just one really key example.
RISC-V may well succeed but not because it's like Linux.
It's more like POSIX or something from that comparison.
Didn't OpenRISC fail? https://en.wikipedia.org/wiki/OpenRISC
Also there are different definitions of "succeed" from different viewpoints. In academia RISC-V is already a big success.
To show difference, OpenRISC has division-by-zero exception which is unnecessary - it can be ruled out by compiler or, if compiler did not rule it out, can be checked and triggered by comparison, conditional jump and special trap command. MIPS did exactly that almost fourty years ago.
OpenRISC also has (optional) branch delay slot, which complicates out-of-order implementations and even in-order implementations with memory mapping unit - what state should you keep to properly handle MMU exception in the branch delay slot command?
Alpha AXP, being the ISA that was designed to be useful for 20-25 years, ditched both of these in early 1990-th. RISC-V, which extends experience of RISC-IV (SPUR [1]) and other RISC designs, including POWER and SPARC, also does not sport these atrocities.
[1] https://news.ycombinator.com/item?id=19266152
All in all, RISC-V represents an ISA that can be implemented differently with less effort than OpenRISC and, to be frank, most other RISC ISAs.
RISC-V started out with the goal of being capable of very small to really large chips and do 32 and 64 bit.
OpenRISC did add 64 bit later but by that point RISC-V was already going.
I started using ESP32C3s in my projects. They are cheap powerful RISC-V micros supported by Arduino SDK. IMHO it's already better than the ARM offerings, but I'm still waiting for good Rust support.
Ideally I'd like something specced closer to a raspberry pi.
I want something I can run Linux, like a raspberry pi but RISC-V. I know there were some bigger development boards out there for $600+ a few years back. Is there anything in the pipes which is smaller, for hobbyist messing around?
Depends on what you do. If you just write code in C/C++, then it doesn't matter. But if you actually like to dabble with assembly code then RISC-V actually makes that possible.
It may not be as awesome to write as 68k was back in the Amiga days, but RISC-V is the closest to that which I have experienced in modern times.
In particular I think RISC-V has a great potential in teaching a new generation how programming works in detail. I felt when I went into this industry that it helped being able to actually read the low level code produced by the compiler and understand it. That is getting ever more difficult.
We are reaching levels of complexity where it becomes very hard to give anyway today the kind of bottom up understanding of how computers work that you could get back in the 80s and 90s.
A non-technical perspective about RISC-V: China is leading to some extent in RISC-V land(Sifive works with Hifive in China, Alibaba released its RISC-V,etc). China could not license x86, could not acquire MIPS, tried to get part of ARM now(the China ARM company is fighting with ARM), but the big land needs to "own" a CPU core at will desperately, RISC-V fits perfectly well.
There are VERY different ideas most notably using variable-length instructions rather than one instruction width (begging the question of whether RISC-V is actually RISC).
Their encoding is completely different, and that's what matters.
https://wiki.debian.org/LoongArch https://gcc.gnu.org/pipermail/gcc-patches/2021-November/5855... https://lists.llvm.org/pipermail/llvm-dev/2021-December/1543...
10/10 would do it again, except this time we may pay SiFive or someone like that for something requiring less "customization".
But, I should also mention, we only use the RISC-V cores as a pre/post-processor, scheduling engine, service processor. We have custom hardware that does the bulk of the inference math (we are a convolutional accelerator with a number of constraints traded off for speed and power). The fabric itself is driven by engines that are programmed by the scheduling engine (RISC-V).
Happy to answer more specific DMs.
You are succeeding? I’ve heard this last four years in a row.
Show me the numbers, shipping units, example of arm designs getting displaced by risc v.
This article is very light on the proof. It is just riscv talking points.
Don’t get me wrong, concept is fine. But at this stage, after hearing about this for years, where is the traction? Prove it.
Apple is not going to adopt it, ARM is still fighting against X86 Imperium in the desktop/server market, and the mobile ecosystem of tooling, compilers, libraries and build process just isn't there.
If RISC-V manages to win education market previously targeted by MIPS and microcontroller, that is already quite good.
So cheerleading for RISC-V to overtake in a couple of years what took ARM 37 years to achieve, is really flying high.
> so cheerleading for RISC-V to overtake in a couple of years what took ARM 37 years to achieve, is really flying high.
Oh yea i agree it won't be a few years. It'll be many years - but it'll move faster than ARM did just because its so much easier to do today than 37 years ago.
I can hardly execute Mac software as old as some stuff I have on Windows floppies, backwards compatibility is what keeps x86 ruling on the desktop.
Yes stuff from 2000 doesn't run today, and yes, its unlikely that web apps will age well, but it does change how people think about software for the average user. A sufficiently large people don't care about backwards compatibility, and apple's graveyard of un-runnable software proved it.
The good news is compute and memory are getting so cheap it's probably not long until RISCV cores just emulate ARM and solve the problem, all inside a greeting card at a profit...
I totally expect intel to offer a RISC V chip in the next decade. Made by them, competing with ARM for low power.
Perhaps they'll try to do another WinTel combo with RISC-V? Sounds like MS can just do it on their own.
The goal is to make money as a fab, not make money as a chip seller to OEMs.
See: https://www.sifive.com/boards/hifive1-rev-b
The more RPi like one actually available, seems to be the Nezha, available on AlieExpress for around $99~170 (and on other places too)
https://fr.aliexpress.com/item/1005002668194142.html
A short review here: https://www.cnx-software.com/2021/05/20/nezha-risc-v-linux-s...
And a extensive wiki page: https://linux-sunxi.org/Allwinner_Nezha
Finally, there also seem to be a BeagleBoard (coming soon or vaporware?) in association with the chinese chip-maker starFive:
Somehow, they're also too stupid to roll their own.
So China/India/Russia/EU/whoever are in fact smart in choosing RISC-V rather than reinventing the wheel for no benefit.
Or smart enough to avoid doing that.
> I don’t believe the success of RISC-V is because it is cheap or lower cost. If you just want to do the same as you can get with an Arm core, you absolutely should just buy an Arm core because it’s so well verified. It’s so well designed. It’s exactly what you want. The only reason for using RISC-V is because you want the freedom to change it and add your own things to it.
RISC-V is great and important as an enabler of innovation and experimentation. As a like for like replacement for the cores in your smartphone less so.
Not looking for investment advice, I myself do not know enough about investment and RISC-V. I'm just curious how one can think about making money from that type of development that may impact a whole part of the industry. I guess one could bet against Intel, but are there other approaches?
Are universities pursuing academic EDA development, too?
(People forget about foundry IP, miscellaneous analog bits of CPUs, the actual physical cost of manufacture, and the question of what "free/libre" actually means for hardware.)
asking for "free" in the face of these factual inputs, appears to echo the most lazy and gluttonous of human instincts.. really unproductive, spoken from a person who has tried to confront the excesses of American markets e.g. software patents, rent-seeking models, etc..
also spoken from a person who defends regularly "free as in Freedom, not free as in BEER" .. this is a call for free beer in the worst form.. really unproductive
The superiority of the ecosystem is debatable. I guess you mostly have proprietary software in mind? (including Microsoft Windows). That will improve with time.
v2 adds for example SSE4.2 and SSSE3, present since Intel Nehalem (first-generation Core i7 etc). I think other families support v2 since Intel Silvermont (Atom), AMD Bulldozer (FX), and AMD Jaguar (AMD E-series). I think one of the bigger losses would be AMD Phenom/Phenom II.
I think Red Hat wants to require x86_64-v2 starting with RHEL9. Arch Linux seems to also have considered it, but seemingly has since decided to support both v1 and v3, to provide both a bigger speed boost and better compatibility with old PC's.
Whereas the "big" CPU providers are staking their reputation and therefore future business on providing a non-backdoored CPU, it would be fairly trivial for an individual device manufacturer to provide a backdoored CPU design for their chip design.
It could become the whole cheap-device OEM firmware situation all over again (as we saw with many backdoored routers), but this time the blob is located on-die, so is significantly harder to reverse engineer or audit.
There is a a general belief that only some good guys have the keys. I don’t know what it is based on.
If anything it's way more difficult that doing so on a closed core.
> It could become the whole cheap-device OEM firmware situation
If you think high-end proprietary routers were not backdoored think again.
It doesn't really matter -- buy why? Most RISC-V decisions were made for some good reason. (also, I'm not convinced RV32E makes sense anymore.)
Now, there is a bit-serial implementation of RV32I, which may indeed benefit from this bit ordering. However, optimizing for an unusual hardware approach (bit-serial) seems sub-optimal.
In other words, I would hope there would be some demonstrable benefit to putting the opcode in the low-order bits when memory fetches are at least 32-bits wide in even the simplest machines.
That being said I am still holding on to my god damn laser disc player until the end !
First of all, it depends on what your goal is. Do you want to create a high-performance general-purpose CPU? Do you want to create a power-efficient CPU? Maybe a special-purpose accelerator? How about a low-cost microcontroller?
Second of all, none of those above are directly dictated by the ISA, but rather by the hardware implementation (think AMD Zen vs Intel Core or the embedded ARM Cortex M4 vs higher-performance Cortex-A53). An ISA can however more easily accommodate certain goals (RISC-V for example is very easily extensible, so if you want to create a special-purpose CPU, it might be right up your alley).
Finally, software also matters a lot. Compiler quality is very important in the resulting performance. I think mediocre compiler support and insufficiently advanced compilers are one of the reasons Intel Itanium never took off, for example. Itanium was a very complex ISA and therefore harder to exploit to its full potential.
Fixed it for you. But hey, it's not like there's anything wrong with that!
An article titled "RISC-V is succeeding" would lead me to expect an article focused on market share over time, which this one is not
Odds are good we're going to be waiting for a while.
Physical limitations or Intel just busted with their research?
Breakthroughs are now architectural, like if someone figured a way to implement a CPU with half as many transistor we could get a ~30% increase in clock frequency
The instruction set has nothing to do with this. Apple has better numbers because it uses the most advanced manufacturing process.
What it does have to deal with is needing several times higher fetch bandwidth. It's all a bunch of tradeoffs.
Related article: https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
Fixed vs. variable is a bunch of powerful tradeoffs.
The way x86 can stack a bunch of prefixes on an instruction is pretty bad though. You have to interpret many pieces of an instruction to find the size.
And AMD is currently the more "low clock/high IPC" of the two major x86 vendors, so they're the easiest comparison, Intel is really clock-focused still (see: today's Anandtech review comparing AMD 6000/Zen3+ against Alder Lake Mobile and note the power scaling numbers).
https://www.anandtech.com/show/17276/amd-ryzen-9-6900hs-remb...
Anyway Jim Keller's "I'm sure x86 isn't dead yet" aside, it seems undeniable that tweaking the instruction set to enable deeper reorder and scale the frontend wider should have performance benefits. Saying out-of-order depth doesn't matter is like saying that code density doesn't matter, or speculation depth doesn't matter. These are things that can be simulated, or measured on real-world code, I don't have numbers at-hand but it seems self-evident that there are metrics that those tweaks should improve on.
It doesn't mean x86 is at the end of the line, but if you told me that a 50-year legacy ISA (even if it's been cleaned up a lot over the last 30) had maybe a 10-20% performance, perf/watt, or area/watt benefit due to "intentional design" (aka tuning to the task) and the knowledge of hindsight - I have no reason to doubt that as being facially untrue.
10-20% is still "competitive", so Keller isn't wrong, but it also still puts x86 at a disadvantage in the long term. That's a generation of memory (Zen3+ got 12% moving to DDR5) or most of an architectural generation or maybe a half-node step that x86 would have to stay ahead to maintain parity (not just competitiveness).
On newer wider and deeper designs this number is most likely smaller, and of course the decoder on Arm or RISC-V consume more than 0% too. So most likely, all in all, the "x86 tax" in terms of power consumption is in the low single digit %.
You're saying "nothing wrong with an n^2 algorithm, it works fine for us with n=1000", when you're comparing against someone who is showing results for n=1M. Obviously it would be better for someone in the latter situation to use an n-log-n algorithm. Not real numbers or transistor order-complexities, but you get the idea, x86 has asymptotically worse transistor complexity than ARM as you increase the decode width, and that is true.
Also, that number is for a full-fat Performance Core. If the rest of the core shrinks, the decoder gets relatively bigger, unless you reduce its performance too. So the amount of decoder area (as a % of the overall core) is worse on efficiency cores than performance cores, because there's less "everything else" there.
(likely you will reduce the decoder somewhat, Goldmont and Gracemont both use a 3-wide instead of 4-wide, but geometric scaling means that it's much more expensive to scale wider than you would save from scaling down. And the reliance on 'tricks' like instruction cache likely won't scale nearly as well - it's the same amount of "hot code" for many tasks, regardless of how many threads are running in it, because most of the work happens in certain hotspots. The increased overhead of decoding could, among other factors, be one of the reasons why Gracemont e-cores are not particularly appealing in perf/area. They are very solid on performance but the area scaling isn't all that great compared to hyperthreaded Golden Cove Performance Cores.)
Also that's really just looking at one part of the processor in isolation. OK, so the decoder only consumes 3-10%, but that doesn't say anything about how it limits the ways the rest of the processor to scale. Everyone loves car analogies, it doesn't matter how big an engine you put in the car if it has a rinky-dink air intake that can't provide enough air to fully utilize its displacement. Looking at "the size of the air intake relative to the size of the engine bay" doesn't give you a realistic picture of how it affects the ability of the rest of the design to scale. A turbo might allow you to scale the rest of the engine up much larger than a naturally aspirated one.
(or maybe the fuel system might be a better analogy...)
As far as the instruction cache - those are tricks can be used on ARM architectures too (and I believe Apple does?), they aren't themselves a substitute for a scalable ISA, they're treating the symptom. They may do more on an architecture that is more bottlenecked in that area, but they do give you at least some speedup on everything. Treating the symptoms is really orthogonal to the topic of how much an ISA limits decoding width or reorder depth in itself.
Anyway, x86 isn't Itanium and it isn't going anywhere, but it strongly looks to me like ARMv8 is on a solid foundation that solves some weaknesses of the x86 design. It's a clean-sheet "how would we do out-of-order/speculation if we could design our instructions over again" and it largely achieves that goal IMO. I don't see it as an inherent law of the universe that "there must exist enough tricks for x86 to match the performance of any competitor". There's always lots of metrics to look at, and in many cases Apple is designing for fundamentally different metrics than AMD/Intel, but I don't quite get the reluctance people have to admit that ARM is going to be better than x86 in some of those metrics, even on iso-node (like A15 vs Zen4). And this is like, the core metric that aarch64 was designed around.
In effect, the argument becomes that decode-to-risc-cost + risc-execution-cost is always going to be bigger than risc-execution-cost.
And this is before you consider the effects of things like looser memory ordering or more registers reducing unnecessary MOVs.
Also, a huge amount of instructions end up being used very little, there are a few "hotspot" instructions that make up a huge percent of actual instructions executed.
https://arxiv.org/pdf/1607.02318.pdf
Measured code density on SPEC2006, ARMv8 has geomean 6% more instructions, and geomean 12% higher code size. But Apple designs use 4x the decoders-per-thread in their Performance Cores compared to Intel (8 decoders for 1 thread for Apple, vs 4 decoders for 2 threads for Intel).
Apple's designs are targeting much, much higher decode performance even considering the lower density of ARM (4/1.06 = 3.77x as much "normalized decode performance per thread"). Which shouldn't be surprising as their IPC is around 3x of modern x86 processors as well according to Anandtech's work on M1. They aren't magic, the code runs about the same on their processors too, they're just designed for much wider layouts than x86 and using super deep re-ordering to get that performance into a single thread.
Quadratic scaling is certainly not ideal, but in the grand scheme of things OoO processors have other components that consume more power as well as having quadratic or even worse scaling. For instance, the issue queue, the ROB, multiported register files, bypass networks.
Hence, when you go to a wider and deeper OoO design I claim that the relative importance of the decoder will decrease.
> If the rest of the core shrinks, the decoder gets relatively bigger,
In the previous paragraph you're arguing that as the core gets beefier the decoder will get relatively bigger. Now you're arguing the exact opposite! So which is it?
> As far as the instruction cache - those are tricks can be used on ARM architectures too (and I believe Apple does?), they aren't themselves a substitute for a scalable ISA, they're treating the symptom. They may do more on an architecture that is more bottlenecked in that area, but they do give you at least some speedup on everything. Treating the symptoms is really orthogonal to the topic of how much an ISA limits decoding width or reorder depth in itself.
I'm quite sure pretty much any processor outside of some really tiny microcontroller will have an instruction cache. But maybe you're talking about micro-op caches. So yes, they are in a way treating the symptom that it can be more efficient to cache decoded instructions instead of decoding them over and over in a loop. But so what, if it works use it! Might as well claim that caching in general is cheating instead of just having faster memory.
> looks to me like ARMv8 is on a solid foundation that solves some weaknesses of the x86 design. It's a clean-sheet "how would we do out-of-order/speculation if we could design our instructions over again" and it largely achieves that goal IMO.
I fully agree, ARMv8 is certainly pretty much a 'best practice' general purpose ISA. I just don't think it's such a dominating factor. If ARM or RISC-V eventually take over the world I think it'll be more due to different licensing/business models/etc rather than the superiority of the ISA itself.
> I don't see it as an inherent law of the universe that "there must exist enough tricks for x86 to match the performance of any competitor".
Indeed there is no such inherent law, but so far looking at the history of microelectronics it seems that with a modest transistor budget penalty and some elbow grease you can make almost any ISA fly.
on the contrary, arm is a simpler isa to implement which means radically less circuitry for reading the instruction. modern Intel cpus go so far as having entire systems that translate external x86 instructions to an internal risc based one. That's a huge source of wasted power ie: heat.
The almost singular advantage ARM has is just the looser memory model, although the best ARM CPU on the market by a landslide (Apple's M1) can run x86's memory model, and it seemingly doesn't cost much (hence how Rosetta 2 can perform so well)
I hope you realize that any big instruction set can be reduced to a smaller instruction set. The only instruction set that cannot be reduced further is a single instruction set.
Then buy AMD? There's choices here, and AMD's laptop CPUs for the last few generations have been very power efficient. See for example today's Anandtech coverage of the latest Zephyrus G14: https://www.anandtech.com/show/17276/amd-ryzen-9-6900hs-remb...
It's nonsensical to think that RISC-V will somehow fix this, since it's a heck of a lot more about execution quality than ISA (fine-grained clocking, power gating, sleep states, etc... as well as just an overall efficient cache & instruction execution design).