6 ms·

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 desi

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.

aleph_minus_one 1y ago
> RISC-V is the better sweet-spot See https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 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 https://news.ycombinator.com/item?id=24958423
- sylware 1y ago
  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.
  - thesz 1y ago
    > 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. This is taken straight from the ISA specification. 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.
    - tux3 1y ago
      >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.
      - wren6991 1y ago
        ...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.
      - camel-cdr 1y ago
        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.
    - hajile 1y ago
      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.
  - compiler-guy 1y ago
    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.
    - sylware 1y ago
      ???? 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...
      - compiler-guy 1y ago
        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.
        sylware 1y ago
        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...
    - hajile 1y ago
      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.
- Findecanor 1y ago
  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.
- IshKebab 1y ago
  Yeah that is pretty out of date. I'd say around half of those points have actually been addressed since then.
  - brucehoult 1y ago
    And the other half are true but irrelevant.
    - aleph_minus_one 1y ago
      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.
      - brucehoult 1y ago
        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_bignum_library_test_riscv_vs_arm/ https://www.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignu...
    - IshKebab 1y ago

aleph_minus_one 1y ago

> RISC-V is the better sweet-spot See https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 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 https://news.ycombinator.com/item?id=24958423

sylware 1y ago
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.
- thesz 1y ago
  > 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. This is taken straight from the ISA specification. 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.
  - tux3 1y ago
    >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.
    - wren6991 1y ago
      ...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.
    - camel-cdr 1y ago
      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.
  - hajile 1y ago
    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.
- compiler-guy 1y ago
  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.
  - sylware 1y ago
    ???? 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...
    - compiler-guy 1y ago
      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.
      - sylware 1y ago
        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...
  - hajile 1y ago
    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.
Findecanor 1y ago
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.
IshKebab 1y ago
Yeah that is pretty out of date. I'd say around half of those points have actually been addressed since then.
- brucehoult 1y ago
  And the other half are true but irrelevant.
  - aleph_minus_one 1y ago
    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.
    - brucehoult 1y ago
      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_bignum_library_test_riscv_vs_arm/ https://www.reddit.com/r/RISCV/comments/1jsnbdr/gnu_mp_bignu...
  - IshKebab 1y ago