> It’s a tradeoff: With RISC-V you get innovation, you can create new extensions, but you lost software compatibility. And more importantly, you lose the guarantee of software compatibility,” he said. Arm’s founders made “that a key tenet, and that will serve us well going forward. I’m confident of that.”
How long does it take until we have server-side Ubuntu Linux and staple applications like PostgreSQL humming nicely on RISC-V? It does not matter if RISC-V has less ported software today, as long as there is clear roadmap when this advantage of ARM will be gone.
If everyone implements their own custom extensions, you would have to compile your software for each RISC-V device. To be able to do that, the compiler needs to support those extensions. I think that is what was meant with "you lost software compatibility".
Edit: I am mistaken, thanks everyone for educating me.
I find it hard to believe there is no way to probe for extensions and provide a fallback
It's a problem that already exists right now.
If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash?
I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented
This is the standard FUD spread around by Arm apologists. Of course you can detect RISC-V extensions at both compile and run time. In fact it's the first widespread ISA that was designed with extension in mind (so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension). This is in stark contrast to x86 where extensions are basically hacks piled on hacks.
> so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension
This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.
> If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash?
Yes. Or it leaves them unused on the machine with avx.
For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.
In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension.
There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
You can choose which extensions to support at compile time and whether this extension is optional. E.g. many binaries don't use AVX at all, while binaries compiled with -march=native may assume that AVX is supported (and emit SIGILL if not).
With x86 there are common extensions that form a baseline (eg. you need SSE2 for any program to run at all). And there are more specialized extensions, eg. for high performance mathematical work. The specialized extensions can usually be confined to a library, and the library can work out at runtime what the hardware supports and swap in optimized functions.
It'll likely work much the same way for RISC-V, eg. in Fedora we require that the C (compressed) extension is supported, otherwise the distro won't boot, and things like the vector extension will probably be used only by specialized math libraries and the like.
Forgive my ignorance if there’s an answer, but for x86, those extensions don’t overlap (mainly because Intel and AMD avoid stepping on each other). RISC-V doesn’t have a guarantee of non-overlapping vendor extensions, no?
There's no way to prevent overlapping extensions. One could easily make an x86 extension that overlaps with some existing one. There's just as much an incentive to not do that for x86 as there is for RISC-V.
See AMD's SSE5 vs Intel's SSE4 conflict in x86 - both have instructions that the other doesn't have, and some that both have, and, from what I understand, even the instruction formats conflict.
You’ll have trouble shipping that extension. Not because it conflicts with AVX2, but because Intel will sue you for your comparability with the rest of x86.
Isn't it the same with some ARM vendors ? Of course, a random foundry can't, but what's preventing Apple from including specific instructions on their core (not that it would make sense) or a specific coprocessor that may or may not be integrated ?
Apple does ship custom instructions on their code but does not expose it to third parties: their external compilers will not generate those instructions, and they remain in the kernel and system libraries where they can be hidden behind APIs without being directly exposed.
The Arm guy is talking nonsense as you'd expect. Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later. I just started a PostgreSQL server on one of my (four) RISC-V machines here:
● postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vend>
Active: active (running) since Sun 2022-02-13 06:56:50 EST; 1s ago
Process: 1861715 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgres>
Main PID: 1861722 (postmaster)
Tasks: 8 (limit: 9510)
Memory: 15.6M
CPU: 262ms
CGroup: /system.slice/postgresql.service
├─1861722 /usr/bin/postmaster -D /var/lib/pgsql/data
├─1861746 postgres: logger
├─1861752 postgres: checkpointer
├─1861753 postgres: background writer
├─1861754 postgres: walwriter
├─1861755 postgres: autovacuum launcher
├─1861756 postgres: stats collector
└─1861757 postgres: logical replication launcher
Feb 13 06:56:50 five systemd[1]: Starting PostgreSQL database >
Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.>
The biggest problem I had was remembering the name of the Fedora PostgreSQL package and that I had to initdb before starting the service. If the Arm CEO really believes software compatibility/availability is Arm's moat then I'm afraid he's in for a big shock.
That's a cheap shot as the highend has long lead time, but the momentum hasn't died, it has only picked up. Personally I have more RISC-V embedded silicon than I have a count on, but of "application class" (= 64-bit with MMU that can run Linux), I have many boards that spans three completely distinct design origins and backing companies. And it's a multinational mix.
The growth of RISC-V will come from the innovation that the freedom allows. Literally anyone looking to design their own core from scratch will consider RISC-V and many have chosen it (Rivos, Tenstorrent, Esperanto Technologies, Alibaba, and many others I forgot).
It's unlikely to happen for a long time. The only reason the RPi exists is because they can divert some Broadcom chips which are produced in vast volumes for things like set-top boxes, get them for a few dollars, and package them as SBCs.
There was a run of ~ 5 million AllWinner chips and Beagle packaged one into a board which I have, which would have sold for sub $200, but they decided not to pursue the idea.
This was the case at first, but they are so big today that there are dedicated RPi chip runs (in fact, I believe they are the only thing using the RPi 4 processor).
ARM also has a good chunk of compatibility issues... There are plenty of times I've had ARM7 vs NEON vs thumb vs big endian/little endian issues...
Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...
Maybe this is naive - but why is software compatibility so important for servers (that mostly run open source software, like psql)? I assume none of it is written in ARM/x86 assembly language and all of it in higher level languages like c/c++/python/java/js/etc that can be compiled/run on RISC-V?
Old timers remember when "compiling open source C code to this other platform" was a real chore. Ever run the old school GNU configure and watched the giant stream of compatibility tests for weird architectures that go by? It's for a reason, one nearly forgotten in our current amd64 monoculture.
The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.
This is just the peak of irony from the guys that couldn't be bothered to copy ACPI for 30 years plus requiring anything running on ARM to set up a bespoke firmware build. That's before you get into all the hard/soft-float, thumb, non-thumb mess and toolchains targeting ARMv6jwzufgka.
I honestly done understand they hype around RISC-V, it’s seems like reinventing the wheel. Sure it’s open, but so is OpenPower; and that’s a lot more mature with better software support. I’m sure it’s not the only one either. Everything new is old I guess.
Edit: Tesla lies in their marketing, the industry is sexist, Rust is overhyped, Wayland still isn't very usable. If I'm gonna get downvotes, I might as well go big.
I mean you're right, but OpenPower showed up late to the game, after the RISC-V hype train was already going, almost as if IBM wanted to derail it. (More likely IBM saw RISC-V prove that it was viable and wanted people to be using Power instead. (So not so much derail it as derail it and put me on the rails instead))
There have been non-Sun/Oracle CPUs available since the 1990s. Fujitsu sells entire product lines on them (and there's a Top 500 cluster built around SPARC.)
I dont think SPARC is a very good ISA. Before RISC-V there was also OpenRISC, which early on had some of the same traction as RISC-V in the open source community. But both SPARC and OpenRISC has branch delay slots, which was, if I remember correctly, one of the things the designers of RISC-V wanted to avoid to have a more scalable ISA. Branch delay slots are supposedly a big issue when designing high end superscalar cores.
RISC-V is very well thought out when it comes to scaling from the smaller MCU cores to the largest supercomputer CPUs. With a coming revision the code density with the compressed extension is even better than ARM Thumb, while being better designed than Thumb (no mode switching)
If anything, it's a clean slate design and that makes it way simpler than the legacy ISA's. To the point that a single, easy to target base ISA can be used for anything from bare-metal embedded devices to high-end supercomputers and hyperscale server hardware. That's quite unprecedented.
The chinese want it. The open crowd thought they are in charge. And given the broken patent process when it will be invoked. It will run for awhile before what the reality is biting. Still early stage.
But just playing architecture game is hard. You need some reasons like lower power … for it to play.
OpenPower was not 'open'. They were fake open for marketing reasons. You could not simply build an OpenPower chip and sell it.
Actually only long after RISC-V both OpenPower and MIPS opened up more.
The only thing that was actually open was SPARCv8 and that had a number of limitations that the creates of RISC-V didn't want. And Oracle had closed it up again after that.
OpenRISC was more a chip, not really an ISA design. And it wasn't 64 Bit when RISC-V started either.
And RISC-V also does a number of new things and removes some other things.
All of this has been extensively written about by the creators of RISC-V, you could just go read it.
> Not unexpectedly, Nvidia this week pulled the plug on its bid to buy RISC-V competitor Arm after the $66 million deal was scuppered by regulators in multiple jurisdictions.
At this moment, the relevant information about Arm is that it competes with x86. RISC-V is no more relevant than Elbrus, though obviously that's going to change.
This statement doesn't appear grounded in facts. Arm was clearly concerned with RISC-V _years_ ago and the competition from RISC-V is far more severe today. I don't claim that Arm will go away anytime soon, but RISC-V is a viable alternative especially in the embedded realm and that will be used for pricing pressure. Long-term, I suspect economics will play out as they always do in the tech sector.
Sometimes, I wonder, what if Jim Keller decided to take on RISC-V and delivered an open source implementation, which is as good as current x86 or ARM hardware. People / companies would move swiftly I guess.
It's a 6-issue design supposedly, so it should be about as wide as the ARM X1/X2 chips. If they open source this design, it could be very interesting for ARM moving forward.
RISC-V is going to bite at the low end embedded market where pennies matter, but it'll be a while before it eats into ARM at the mid to high end. ARM is offering non-discriminatory licenses at unit prices that are largely an irrelevance on the retail cost of a mobile phone or laptop. So it's going to take a long time to convince manufacturers that they want a non-compatible chip versus a few cents extra to get the well known one with all the support.
Not easily as their terms are private, but you can tell it's not a huge slice. Fairly well every phone and all manner of other devices uses an ARM but I'm googling their royalty revenues at $1.3 billion dollars annually. So that's not much per device shipped. Stuff you hear suggests maybe they get 1% on the sale price of a CPU. Note that's the CPU price, not the phone. The CPU in a phone might cost e.g. $20 so they maybe get 20 cents off that. I expect they have other revenues from design assistance and support etc but those costs would apply to a RISC-V device also.
Everything is confidential, but you can get an idea. Arm's revenue on a phone CPU likely pennies, or at the highest end a buck. They just make it up in volume. The interesting point is how.
First, you can see from a recent HN post that an electric toothbrush contains a 32-bit ARM CPU. If you've built any hardware you'll know that your BOM is king, and you try to squeeze that on the back of your OEMs. So Philips isn't paying much for that CPU and the CPU vendor (who could be Philips) would choose a different CPU if the royalty payment was too high.
By taking a tiny bite out of a huge number of parts ARM both spreads out its risk (the parts are ubiquitous) and starves the market of oxygen: there just isn't enough revenue for many or any competitors to get started. They'd have to lose money for years, or even decades, to get to the break even point.
And don't forget what ubiquity means: that phone doesn't have an ARM CPU: there is ARM logic in all sorts of devices inside the phone, from the baseband processor to probably integrated logic in the camera (even if the CPU has ISP logic) to USB PHYs to who knows what. With a few pennies or less on each one. Those headline CPUs may have the highest royalty rate for all we know.
The real question is why Apple uses ARM. Yes they have a longstanding history back to the founding of ARM but they are masters of cutting their BOM. They have an architectural license, and have their own microarchitecture. They make their own toolchain soup to nuts. They don't have to worry about compatibility with anyone outside their ecosystem. So why bother to pay anything to ARM?
I've been asking around and the best (and consensus) theory I've been able to get is patents. That architectural license would presumably contain rights to all of ARM's patents.
If that theory is correct, that's a huge threat to RISC V. I doubt ARM would ue, or even threaten to sue any RISC V user now: they'd look like Goliath beating up David. But once RISC V starts to get noticeable traction, and especially if ARM is a public company, patent licensing will start to matter. Their smartest strategy would be to pull a Microsoft and force companies to simply pay ARM a royalty for every RISC V they ship.
Note: I'm a fan of the RISC V and not particularly a fan of ARM. But I recognize that ARM has played the long game quite well.
Apple has been an ARM licensee since they were a founding shareholder in ARM. They used it in the Newton, but now of course it's ubiquitous in their products.
The effort to design their own instruction set (including all the tooling) would not be trivial, but probably not enormous for them given their scale. And given their scale, their license must be cheaper than the cost of that activity, because you know Cook would pay it if it would save them enough down the road.
Apple has deep pockets, but using an existing ISA gives you a lot of OSS porting and optimization work for free. They could just use RISC-V if they wanted to and still have all the flexibility they want.
Given the amount of software they write from scratch, and that they have their own tool chains, the actual ISA is below Apple’s noise floor. I’m sure they spend more on optimizing for the quirks (cache size, instruction timing, etc) of each generation of chip.
RISC-V has been specifically designed so that the ISA itself doesn't use anything that's recent enough to be possibly patent encumbered. There might be risk involved in some chip designs, but these can be seamlessly replaced if needed.
This seems like a reasonable theory but I’m not sure the framing as ‘Arm pulling a Microsoft and forcing companies to pay for every RISC-V chip’ is quite right.
Apple has had access to all Arm’s IP - eg for example on big.LITTLE. Isn’t it right that Apple (market cap around $3tn) actually pays for that IP if they want to use it on another ISA?
Also maybe Apple has decided that Aarch64 is a better choice for their higher end CPUs and it’s worth the extra cost? That would surely outweigh any consideration in terms of cost given how small a part of the BOM this is.
> Apple has had access to all Arm’s IP - eg for example on big.LITTLE. Isn’t it right that Apple (market cap around $3tn) actually pays for that IP if they want to use it on another ISA?
Yes, this is my point: there’s little reason to change if you’d just have to keep paying the same.
> Also maybe Apple has decided that Aarch64 is a better choice…
Remember that Apple has a full architecture license and their microarchitecture is their own. Their parts don’t really look like anybody else’s except having mostly the same instruction set. I really don’t think the ISA itself would be anything they would spend any time thinking about either way — other factors dominate.
We're broadly in agreement - my concern was the implication that Apple can't switch because they'd be sued and therefore there is a wider concern for the broader RISC-V ecosystem.
Apple would deserve to be sued if they tried to take Arm's IP that they've had access to for years and apply it to another ISA for free. Doesn't have any read across for a RISC-V designer that doesn't have access to / isn't using that IP.
There are two questions here, not to be conflated:
1: given that apple has their own architecture that happens to implement some of the ARM ISAs, what are they really paying for with their license? The conjecture is: primarily patents. ARM supplies a lot of tooling but I doubt much of that is usable in Apple’s environment, except some of the most surface stuff (ISA conformance, perhaps). At this point I doubt there’s a lot of ARM IP in apple’s parts except for the copyrights on the ISA and patents, which anyone can read.
2: patents can apply to other MPU vendors/developers even if they don’t read them. In fact the “best” (i.e. most horrible) way to enforce them is to wait until vendor gets enough traction and then demand a license be purchased.
1. Maybe, although we don't really know and there is almost certainly stuff that Apple has access to which isn't patents - can they pick up the phone to someone at Arm to discuss and get help on an issue - very likely. Plus as I've said before those patents and associated IP might be integral to Apple's designs and they absolutely should pay for them.
2. Of course, that's just how patents work. But there is no evidence that Arm is doing this.
Overall, I don't agree with the sense that Arm is an overhead for Apple that if it weren't for those pesky patents they would cast aside and cut their costs. I think it's more complex than.
The industry ( Smartphone ) uses ARM and that benefited Apple enormously. All the open source software that apple deploy and uses inside iOS as well as LLVM compiler tool chain. Apple benefited these R&D in value are being spent from Android as well. Instead of Apple being the sold owner and maintainer of its own ISA.
At the end of the day ISA doesn't really matter from Apple's POV. It make less sense now when Apple now has an array of their own ARM implementation to choose from. Since they dont need to pay per unit it makes very little sense to switch.
I remember few years back ARM's CEO was giving presentation at AMD conference, and he explained ARM's strategy as such: Rather that taking a bigger slice of a smaller pie, we take a smaller piece of a very large pie.
There are only really two drivers for RISC-V at this point - license fees and Arm's insistence that unless you are Apple, you have to comply with the ISA exactly.
Both are something Arm can adjust at any point and is in the process of adjusting post-Nvidia-collapse. All it is going to take is for Arm to stand up a review process to deal with the problem gracefully.
Just curious, where aren’t they complying with the ISA? I know they use a couple registers in specific ways, but IIRC, the way they use it was left to the implementer so they aren’t diverging from the architecture.
You're missing the point. It's not the cost but the fact that it has to be purchased that becomes a barrier to development and experimentation. Having to negotiate a licence even before you get started on a project can kill it.
You have to compare it to open source. Why are so many open source projects so popular? It's not the cost, corporations don't mind paying. It's the freedom to go in whatever direction any person wants to go without restriction that produces innovative software.
The comparable model for RISC-V is Linux and Redhat (et al), and on that basis it will win like Linux won. That combined with a clean and simple design.
It should be clear what is happening here. Intel sees Arm as a competitive threat in its high margin desktop and server cpu business. Supporting RISC-V as an Arm competitor at the low end weakens Arm and lessens that competitive threat.
I think the key enabler for architecture diversity will be a jit-based OS kernel. Interpreters are an N-to-N problem, and build systems often fail. IR distributions seem most robust.
I hope this not an "embrace, extend and extinguish" strategy. If the ARM and Nvidia deal had gone through, it would have been a major headache for Intel. Now that is off, Intel has less things to worry about on the architecture front apart from RISC-V.
The ISA is moving toward being a commodity and nothing is going to stop that.
Intel has more money to put into chip design. They already have all the IP and patents for the non-RISCV parts of the chip and chipset. They could literally design a drop-in replacement in their current motherboards and go straight to market years before all this stuff gets tested and shipped by the competition.
Just as important, they have the business connections and reputation of delivering. Those may be less tangible, but the best chip in the world doesn't mean anything if you can't move it to customers.
They seem very strongly positioned even if they never have any input into the ISA itself.
They have an even stronger position in x86, where they are the dominant player in a duopoly, with new entrants denied access.
So yes, they might be interested in helping RISC-V in order to hurt Arm on the low end, but I'm sure they're not looking forward to RV eating a chunk of the x86 market.
They are getting stomped by ARM on the high-end too.
X2 is quite a bit faster per clock than every x86 (except maybe golden cove).
It's only a matter of time before these start flowing into the high-end market and disrupt. Jim Keller is currently overseeing a 6-issue RISC-V core (same width as Intel's latest/greatest golden cove chip) that will allegedly be open-sourced too.
This is a very dangerous situation for them.
It seems better to milk x86 for all it's worth while leveraging RISC-V for all it's worth. If they can offer custom x86 compatibility with their RISC-V designs, that's just one more way to ensure they cut out the rest of the market and keep their lead.
RISC-V will win because there will be intense competition to be the best cpu core IP for any given market segment. Whereas ARM & x86 each have only a couple of companies competing with each other once you're fully committed to using them.
The real money is in SoCs or end user devices not processor IP. Thus that’s where the resources to build the best cores will tend to go.
If you had a second Arm selling licensed cores against Arm v1 would competition result in better cores? Maybe but it’s equally likely that it would make it harder for either company to compete for talent against Apple and Qualcomm.
You're trying to argue that the 'open market' in licensed designs results in better cores. I'm pointing out that the best cores today (and likely in the future) come from those with deep pockets - SoC / device manufacturers.
Maybe there will be a better / cheaper RISC-V equivalent of an A75 say but I'm honestly not that bothered.
>You're trying to argue that the 'open market' in licensed designs results in better cores.
No. There, you are wrong. Maybe this is something that you are worried about?
What I was "trying to say" is that a company that needs a core now has at least these two options: License an ARM chip from ARM, license a RISC-V chip from somebody else.
Somebody else there means the tens of vendors that are licensing their cores. A RISC-V core there would be one among the hundreds available. These numbers are growing every month.
Picking ARM means you're stuck with ARM. Maybe you already are using ARM, and remaining there while keeping an eye on the market is your choice for now.
Picking RISC-V means you're free to pick from a variety of vendors, and switch vendors anytime you wish. Some cores are even OSHW licensed, which means free as long as you don't need something better/not at your own risk. The point is not being stuck, thanks to RISC-V compliance.
It is not surprising ARM is worried about this. They're doing PR trying to present their advantages and throw in FUD against RISC-V.
117 comments
[ 4.1 ms ] story [ 256 ms ] threadHow long does it take until we have server-side Ubuntu Linux and staple applications like PostgreSQL humming nicely on RISC-V? It does not matter if RISC-V has less ported software today, as long as there is clear roadmap when this advantage of ARM will be gone.
Edit: I am mistaken, thanks everyone for educating me.
It's a problem that already exists right now.
If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash?
I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented
This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.
Yes. Or it leaves them unused on the machine with avx.
For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.
Things like OpenJDK, pixman, nss, ffmpeg.
There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
Profiles. See RVA22.
It'll likely work much the same way for RISC-V, eg. in Fedora we require that the C (compressed) extension is supported, otherwise the distro won't boot, and things like the vector extension will probably be used only by specialized math libraries and the like.
See AMD's SSE5 vs Intel's SSE4 conflict in x86 - both have instructions that the other doesn't have, and some that both have, and, from what I understand, even the instruction formats conflict.
One cannot easily make an x86 extension because there are approximately ~3 entities on the planet allowed to make x86 extensions.
I wouldn't be surprised if Sony/Microsoft did too for their consoles.
It's doable if you have enough money to get AMD or VIA to make you a one-off.
https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangop...
https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-ris...
There are also the expensive dev boards from SiFive as well as the softcores from zepan. I think Alibaba and Rockchip will be available soon as well
Jean-Luc's website is great for tracking this space:
https://www.cnx-software.com/news/risc-v/
- 2 x HiFive Unleashed
- 2 x HiFive Unmatched
and on the shelf:
- Beagle V Beta (they decided not to proceed)
- PolarFire
- various FPGA-based RISC-V impls, notably a Lattice running PicoRV32
The growth of RISC-V will come from the innovation that the freedom allows. Literally anyone looking to design their own core from scratch will consider RISC-V and many have chosen it (Rivos, Tenstorrent, Esperanto Technologies, Alibaba, and many others I forgot).
EDIT: typos
my understanding is that would be a gamechanger because many people would be exposed to it. right?
There was a run of ~ 5 million AllWinner chips and Beagle packaged one into a board which I have, which would have sold for sub $200, but they decided not to pursue the idea.
https://aliexpress.com/item/1005003741287162.html
Any idea whether distros are planning to move towards the upcoming RVA22 profile or are they going to remain on GC?
* https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/
* https://www.openbsd.org/riscv64.html
Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...
Debian is almost entirely ported to RISC-V and it's been the biggest early adopter.
96% of the packages are ported: https://wiki.debian.org/RISC-V#Progress
What is missing is powerful and inexpensive CPUs. (Easier said than done)
To this day writing ARM lambdas on AWS has its own gotchas.
Idk, I think their CEO has a point, it's just that it might be a short lived one given how much money Chinese companies are throwing at risc V.
The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.
Edit: Tesla lies in their marketing, the industry is sexist, Rust is overhyped, Wayland still isn't very usable. If I'm gonna get downvotes, I might as well go big.
* https://sparc.org
There have been non-Sun/Oracle CPUs available since the 1990s. Fujitsu sells entire product lines on them (and there's a Top 500 cluster built around SPARC.)
This also included the 'BIOS' (IEEE 1275-1994):
* https://en.wikipedia.org/wiki/Open_Firmware
And accessory bus (IEEE 1496-1993):
* https://en.wikipedia.org/wiki/SBus
RISC-V is very well thought out when it comes to scaling from the smaller MCU cores to the largest supercomputer CPUs. With a coming revision the code density with the compressed extension is even better than ARM Thumb, while being better designed than Thumb (no mode switching)
I'd love to read about this revision and understand how it achieves that improvement. Do you have a link handy?
Vectoring being one of the best features.
I agree with everything else but RV is actually a big improvement over OpenPower and many other ISAs.
But just playing architecture game is hard. You need some reasons like lower power … for it to play.
Actually only long after RISC-V both OpenPower and MIPS opened up more.
The only thing that was actually open was SPARCv8 and that had a number of limitations that the creates of RISC-V didn't want. And Oracle had closed it up again after that.
OpenRISC was more a chip, not really an ISA design. And it wasn't 64 Bit when RISC-V started either.
And RISC-V also does a number of new things and removes some other things.
All of this has been extensively written about by the creators of RISC-V, you could just go read it.
Million, really? Off by a factor of 1,000?
At this moment, the relevant information about Arm is that it competes with x86. RISC-V is no more relevant than Elbrus, though obviously that's going to change.
https://youtu.be/KOHQQyAKY14
If I recall correctly, some things were planned to be open sourced.
First, you can see from a recent HN post that an electric toothbrush contains a 32-bit ARM CPU. If you've built any hardware you'll know that your BOM is king, and you try to squeeze that on the back of your OEMs. So Philips isn't paying much for that CPU and the CPU vendor (who could be Philips) would choose a different CPU if the royalty payment was too high.
By taking a tiny bite out of a huge number of parts ARM both spreads out its risk (the parts are ubiquitous) and starves the market of oxygen: there just isn't enough revenue for many or any competitors to get started. They'd have to lose money for years, or even decades, to get to the break even point.
And don't forget what ubiquity means: that phone doesn't have an ARM CPU: there is ARM logic in all sorts of devices inside the phone, from the baseband processor to probably integrated logic in the camera (even if the CPU has ISP logic) to USB PHYs to who knows what. With a few pennies or less on each one. Those headline CPUs may have the highest royalty rate for all we know.
The real question is why Apple uses ARM. Yes they have a longstanding history back to the founding of ARM but they are masters of cutting their BOM. They have an architectural license, and have their own microarchitecture. They make their own toolchain soup to nuts. They don't have to worry about compatibility with anyone outside their ecosystem. So why bother to pay anything to ARM?
I've been asking around and the best (and consensus) theory I've been able to get is patents. That architectural license would presumably contain rights to all of ARM's patents.
If that theory is correct, that's a huge threat to RISC V. I doubt ARM would ue, or even threaten to sue any RISC V user now: they'd look like Goliath beating up David. But once RISC V starts to get noticeable traction, and especially if ARM is a public company, patent licensing will start to matter. Their smartest strategy would be to pull a Microsoft and force companies to simply pay ARM a royalty for every RISC V they ship.
Note: I'm a fan of the RISC V and not particularly a fan of ARM. But I recognize that ARM has played the long game quite well.
The effort to design their own instruction set (including all the tooling) would not be trivial, but probably not enormous for them given their scale. And given their scale, their license must be cheaper than the cost of that activity, because you know Cook would pay it if it would save them enough down the road.
Apple has had access to all Arm’s IP - eg for example on big.LITTLE. Isn’t it right that Apple (market cap around $3tn) actually pays for that IP if they want to use it on another ISA?
Also maybe Apple has decided that Aarch64 is a better choice for their higher end CPUs and it’s worth the extra cost? That would surely outweigh any consideration in terms of cost given how small a part of the BOM this is.
Yes, this is my point: there’s little reason to change if you’d just have to keep paying the same.
> Also maybe Apple has decided that Aarch64 is a better choice…
Remember that Apple has a full architecture license and their microarchitecture is their own. Their parts don’t really look like anybody else’s except having mostly the same instruction set. I really don’t think the ISA itself would be anything they would spend any time thinking about either way — other factors dominate.
Apple would deserve to be sued if they tried to take Arm's IP that they've had access to for years and apply it to another ISA for free. Doesn't have any read across for a RISC-V designer that doesn't have access to / isn't using that IP.
1: given that apple has their own architecture that happens to implement some of the ARM ISAs, what are they really paying for with their license? The conjecture is: primarily patents. ARM supplies a lot of tooling but I doubt much of that is usable in Apple’s environment, except some of the most surface stuff (ISA conformance, perhaps). At this point I doubt there’s a lot of ARM IP in apple’s parts except for the copyrights on the ISA and patents, which anyone can read.
2: patents can apply to other MPU vendors/developers even if they don’t read them. In fact the “best” (i.e. most horrible) way to enforce them is to wait until vendor gets enough traction and then demand a license be purchased.
2. Of course, that's just how patents work. But there is no evidence that Arm is doing this.
Overall, I don't agree with the sense that Arm is an overhead for Apple that if it weren't for those pesky patents they would cast aside and cut their costs. I think it's more complex than.
The industry ( Smartphone ) uses ARM and that benefited Apple enormously. All the open source software that apple deploy and uses inside iOS as well as LLVM compiler tool chain. Apple benefited these R&D in value are being spent from Android as well. Instead of Apple being the sold owner and maintainer of its own ISA.
At the end of the day ISA doesn't really matter from Apple's POV. It make less sense now when Apple now has an array of their own ARM implementation to choose from. Since they dont need to pay per unit it makes very little sense to switch.
Unless you are into very specific usage.
Both are something Arm can adjust at any point and is in the process of adjusting post-Nvidia-collapse. All it is going to take is for Arm to stand up a review process to deal with the problem gracefully.
https://news.ycombinator.com/item?id=25801500
You have to compare it to open source. Why are so many open source projects so popular? It's not the cost, corporations don't mind paying. It's the freedom to go in whatever direction any person wants to go without restriction that produces innovative software.
The comparable model for RISC-V is Linux and Redhat (et al), and on that basis it will win like Linux won. That combined with a clean and simple design.
A move like that could just as easily push ARM to go all in on servers and desktops and harm Intel even more.
Seriously though the key issue now is does Arm have resources to invest in better designs - weaken cashflow and that’s in doubt.
Intel has more money to put into chip design. They already have all the IP and patents for the non-RISCV parts of the chip and chipset. They could literally design a drop-in replacement in their current motherboards and go straight to market years before all this stuff gets tested and shipped by the competition.
Just as important, they have the business connections and reputation of delivering. Those may be less tangible, but the best chip in the world doesn't mean anything if you can't move it to customers.
They seem very strongly positioned even if they never have any input into the ISA itself.
So yes, they might be interested in helping RISC-V in order to hurt Arm on the low end, but I'm sure they're not looking forward to RV eating a chunk of the x86 market.
X2 is quite a bit faster per clock than every x86 (except maybe golden cove).
It's only a matter of time before these start flowing into the high-end market and disrupt. Jim Keller is currently overseeing a 6-issue RISC-V core (same width as Intel's latest/greatest golden cove chip) that will allegedly be open-sourced too.
This is a very dangerous situation for them.
It seems better to milk x86 for all it's worth while leveraging RISC-V for all it's worth. If they can offer custom x86 compatibility with their RISC-V designs, that's just one more way to ensure they cut out the rest of the market and keep their lead.
Not very competitive when the only company that can license ARM cores to third parties is ARM itself.
If you had a second Arm selling licensed cores against Arm v1 would competition result in better cores? Maybe but it’s equally likely that it would make it harder for either company to compete for talent against Apple and Qualcomm.
How does that even matter? You cannot license Apple's leading ARM cores.
Maybe there will be a better / cheaper RISC-V equivalent of an A75 say but I'm honestly not that bothered.
No. There, you are wrong. Maybe this is something that you are worried about?
What I was "trying to say" is that a company that needs a core now has at least these two options: License an ARM chip from ARM, license a RISC-V chip from somebody else.
Somebody else there means the tens of vendors that are licensing their cores. A RISC-V core there would be one among the hundreds available. These numbers are growing every month.
Picking ARM means you're stuck with ARM. Maybe you already are using ARM, and remaining there while keeping an eye on the market is your choice for now.
Picking RISC-V means you're free to pick from a variety of vendors, and switch vendors anytime you wish. Some cores are even OSHW licensed, which means free as long as you don't need something better/not at your own risk. The point is not being stuck, thanks to RISC-V compliance.
It is not surprising ARM is worried about this. They're doing PR trying to present their advantages and throw in FUD against RISC-V.