> 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
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
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.
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.
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...
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.
Come on...
But a real-life ISA doing a good enough job, without any global strong IP locks like x86-64 or arm... yummy.
> Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care.
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.
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.
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.
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.
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...
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.
There are much more toxic fan boys than some other fan boys...
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.
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... )
Well, could not really make the difference between RISC_V and ARM64.