RISC-V is the better sweet-spot, and has no strong IP locks like arm or x86_64. Not to mention the silicon of nowdays changes everything: you avoid silicon design complexity as much as possible since it will be more than performant enough for the bulk of the programs out there.
> RISC-V is the better sweet-spot
See https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99... for an ex-ARM's engineer's critic of RISC-V.
HN discussion: https://news.ycombinator.com/item?id=24958423
That discussion is five years old and a lot has happened in the RISC-V world since.
64-bit RISC-V finally achieved feature-parity with 64-bit ARM, with the RVA22 and RVA23 profiles. (There are no RVA23-compliant chips taped out yet, but several are expected early next year)
RISC-V's core was intentionally made small, to be useful for teaching and for allowing very tiny cores to be made for embedded systems. The extensibility has resulted in a few trade-offs that are different from ARM and can definitely be discussed, but the extensibility is also one of the RISC-V ecosystem's strengths: Embedded chips can contain just the extensions that are needed. Proprietary extensions are also allowed, which have been used to prototype and evaluate them when developing official extensions.
For any fair comparison between ARM and RISC-V, you should compare the right ARM ISA against the right RISC-V ISA. ARM Cortex-M0 against RV32IC, ARMv9 AArch64 against RVA23, etc.
Yeah that is pretty out of date. I'd say around half of those points have actually been addressed since then.
And the other half are true but irrelevant.
OK, if it has been addressed or it is irrelevant:
How do I do an "add with carry" (or subtract with carry/borrow) on RISC-V (for this, of course, the addition has to set a carry flag, and the subtraction either has to set a carry or borrow flag).
This feature is very important for a high-performant implementation of arbitrary-precision arithmetic.
Yes yes that's the other widely quoted criticism of RISC-V, from a GNU MP maintainer.
At the time there was no widely-available RISC-V hardware. There is now, and earlier this year I tested it.
It turns out that the GNU MP project's own benchmark runs better on SiFive RISC-V cores than on comparable µarch Arm cores, specifically better on U74 than on A53, and better on P550 than on A72, despite (obviously) the Arm cores having carry flags and ADC instructions and the RISC-V cores not having those.
The ensuing discussion also came to a consensus that once you get to very wide cores e.g. 8+ like Apple's M1 and several upcoming RISC-V cores, carry flags are ACTIVELY BAD because they serialise the computation (even with OoO, renaming the flags register etc) while only one 64 bit A + 64 bit B + 1 bit carry-in limb computation in 18,446,744,073,709,551,616 has an actual carry-out dependency on the carry-in, so you can almost always simply add all the limbs in parallel. The carry-in only affects carry-out when A+B is exactly 0xFFFFFFFFFFFFFFFF.
Full thread here:
https://www.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignu...
Well, maybe. I feel like he still has a point with array indexing and JAL.
Stand-alone array indexing, not in a loop, is quite rare and seldom affects code speed. When it is in a loop, the calculation is usually strength-reduced to a bump of a pointer by a constant, so things such as scaled register indexing aren't actually used a lot.
It is true that there is a range of offsets between ±1 MB and ±128 MB in which arm64 can use a single BL instruction while RISC-V's JAL won't reach. Both need two instructions (8 bytes) for a ±2 GB subroutine call. You'd have to analyse program traces to find out how important this it in practice.
I haven't done that study myself, but I expect it would be a losing thing to bet that one of the authors (and his students / colleagues) of the famous "Computer Architecture: A Quantitative Approach" textbook didn't think to do this while making ISA design tradeoffs.
RISC-V does get genuine extra utility from being able to use other registers as the link register e.g. using the `-msave-restore` compiler flag to call runtime functions to save and restore registers instead of having load/store multiple, and being able to call that function before saving the Link Register.
I mean, that goes for the array indexing thing too, and all the other criticisms erincandescent makes. It's a very easy thing to say that constants and offsets should always be bigger, better, instruction sequences shorter but you then have to ask what else should be left out to make room, especially in an ISA with fixed-length instructions.
Ofc arm people will go after risc-v: it is a death sentence for them...
Come on...
But a real-life ISA doing a good enough job, without any global strong IP locks like x86-64 or arm... yummy.
A quick Google search for the number of processors shipped in 2024 shows nVidia shipping one-billion riscv _cores_ last year being pretty big news. Assuming they were one fourth of the market, and that there was just one core per chip (certainly not true) that’s four billion cores.
Meanwhile arm licensees shipped twenty-nine billion chips. Most with four cores, and some with many more.
Riscv is on the way up, but any death sentence for arm is decades away.
Qualcomm is rumored to be paying 2-2.5% per chip instead of the 5-5.5% ARM sued them for (some sources claim it was 6-10%).
No matter how you slice up their handset and mobile divisions profits, the current cost is billions just to license an ISA.
Qualcomm could likely pay for most of their chip design costs with the amount of money they’re giving ARM. When contract renewal comes up, Qualcomm will be even more incentivized to move to RISC-V.
Apple has apparently been moving on chip soft cores to RISC-V. At some point (probably around renewal time), they’re likely to want to save money by switching to RISC-V too.
There are even rumors of ARM working on RISC-V cores (I’d guess smaller cores to compete with SiFive).
There’s an economic incentive to change and the only blocker is ARM inertia, but making ARM emulate quickly on RISC-V is almost certainly easier than making x86 and all its weirdness/edge cases run on ARM.
Once the software is in place (getting close) and a competitive RISC-V phone chip exists, I suspect the conversion will be very fast.
> the current cost is billions just to license an ISA.
It used to be that instruction sets were not copyrightable, and you had to resort to implementation patents to extract money (e.g. the MIPS vs Lexra case https://www.eetimes.com/mips-technologies-sues-lexra-for-pat... )
Apple probably pays a lot less than Qualcomm? They have a unique (details unknown) license. They have a license to 2040 now too: https://www.macrumors.com/2023/09/06/apple-inks-new-deal-arm...
I do write RISC-V, x86_64 assembly, and I had to code a bit of ARM64 assembly (because of an old RPI).
Well, could not really make the difference between RISC_V and ARM64.
Most architectures never actually die. New architectures just snap up the balance of the new designs. That said, a competitive license-free ISA is quite attractive to a lot of people, and once the snowball gets moving it will grow in size and pick up speed.
????
Do I really need to add "on the long run"? Because this is super obvious. That stuff does not happen over night :)
You can feel already the pressure of arm fan boys attacking aggressively RISC-V stuff. This is a good sign.
Don't forget: RISC-V has no strong IP ISA locks like arm and x86_64...
In the long run we are all dead. So a “death sentence” far enough out is meaningless. Riscv killing arm is pretty distant.
They will all be replaced sooner or later.
I have no particular affinity for arm or riscv. Playing fan-boi for any technology is silly.
At least, I did not choose the side of an ISA with global super strong IP locks like some...
There are much more toxic fan boys than some other fan boys...
For example, Intel can brand their own chips as RISC-V-ZIntelx8664, if they want to, because RISC-V-Zxxx implementation can be as incompatible with any other RISC-V implementations (and even specification) as one wants.
Honestly, I think the RISC-V guys would LOVE a dual x86/RISC-V hybrid processor as it would make the transition much more smooth.
>RISC-V-Zxxx implementation can be as incompatible with any other RISC-V implementations (and even specification) as one wants.
It can't. Extensions have a lot of freedom, but still have to follow the core spec. You can't just submit amd64 as a riscv extension for a myriad of reasons, it clearly conflicts with the base ISA.
This is also why there is a trademark. If you or Intel wanted to deliberately create nonsense to be disruptive, you are allowed to create it, but then you can't call it RISC-V without receiving some fan-mail from lawyers.
What you could do is add a custom vendor extension, maybe XIntel64, which adds a CSR that can toggle between RISC-V and x86 mode.
...although you could certainly implement a Jazelle-style "branch to x86" instruction if you really wanted. It's fine as long as you come up in RVI mode.
Unfortunately you would not be able to repurpose the LSB of jalr targets as an "x86 bit" à la Thumb because the standard requires you to ignore that bit, though of course you could enable that behaviour with a custom CSR.