5 ms·

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

by inigyou 3mo ago

wren6991 3mo ago
You might find this relevant: RISC-V Genealogy (2016) https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf Or in poster form: https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruction-Lineage-Poster-v6.pdf https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...
- phire 3mo ago
  Yeah, very much legally distinct MIPS, at least as a starting point. The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS. But it also copies a lot of other ideas from MIPS, like the absolute distain for flag registers.
  - _0ffh 3mo ago
    >absolute distain for flag registers It's worst aspect maybe.
    - deleted 3mo ago
      [deleted]
    - wk_end 3mo ago
      The RISC-V specs insist that this is important for simplifying high performance designs, because a flag register is a single piece of shared state that instructions are constantly (and often inadvertently!) touching. This necessarily introduces hazards and serialization. I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.
      - _0ffh 3mo ago
        Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated). I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.
      - phire 3mo ago
        I don't agree with the argument. By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it. And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns. Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed. RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space. Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)
        Permik 3mo ago
        By the time you have an out-of-order core You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state. Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"
fluffybucktsnek 3mo ago
> Of course not because that's impossible to prove. Why?
- hyperhello 3mo ago
  It's supposed to be impossible to prove a negative. But it might still happen some day. We just don't know.
  - fluffybucktsnek 3mo ago
    "it's impossible to prove a negative" is a simplification. A negation is just the oppositive of an affirmation. If the affirmation is "there is an element E of an infinite set S that satisfies property P", the negation would be "there is no E in S that satisfy P", which would make proving by enumeration require checking every element of an infinite set, which is impossible. But other forms of proof might be possible. The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.
    - adastra22 3mo ago
      It was a joke I think.
    - inigyou 3mo ago
      Someone might also file a new parent, then apply it against RISC-V. You'd think that wouldn't be allowed to happen, and maybe it isn't, but only an expensive lawsuit will prove it
      - fluffybucktsnek 3mo ago
        Given the nature of the US legal system as based on common law, that applies beyond patents, and may affect ARM and x86 as well. In the end, the real, effective law is the one understood by judges, adjucated in court cases, built on precedents. That being said, I don't expect someone filing a new patent after a RISC-V extension being published to last much longer beyond discovery in most cases, which should keep costs in lower end. Specially so in cases of bad faith.
pavlov 3mo ago
Patents only last 20 years. If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.
- jurgenburgen 3mo ago
  How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?
  - pavlov 3mo ago
    The first version of RISC-V was released in 2010. It was based on work done at Berkeley in the 1980s (RISC versions one to four). One reason that RISC-V has so many optional extensions is that you can trust the core is very likely to be patent-free (because everything in it is documented to be older than 20 years) and just evaluate the extensions you need.
u1hcw9nx 3mo ago
If you iterate trough every concept RISC-V has, you might be able to prove it. The RISC/MIPS concepts date back over 40 years. The base instruction set is intentionally designed with unencumbered, expired, or public-domain architectural concepts. RICV-V microarchitectures and implementations are at much high risk of violating patents. Especially anything that is even slightly high performance. SiFive, Andes , and Alibaba’s T-Head are filing thousands of patents on microarchitectural optimizations and extensions. China's RISC-V patent-sharing alliances and other industry groups are building defensive patent cross-license around their RISC-V-related patents.

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

by inigyou 3mo ago

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

wren6991 3mo ago

You might find this relevant: RISC-V Genealogy (2016) https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf Or in poster form: https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruction-Lineage-Poster-v6.pdf https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...

phire 3mo ago
Yeah, very much legally distinct MIPS, at least as a starting point. The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS. But it also copies a lot of other ideas from MIPS, like the absolute distain for flag registers.
- _0ffh 3mo ago
  >absolute distain for flag registers It's worst aspect maybe.
  - deleted 3mo ago
    [deleted]
  - wk_end 3mo ago
    The RISC-V specs insist that this is important for simplifying high performance designs, because a flag register is a single piece of shared state that instructions are constantly (and often inadvertently!) touching. This necessarily introduces hazards and serialization. I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.
    - _0ffh 3mo ago
      Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated). I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.
    - phire 3mo ago
      I don't agree with the argument. By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it. And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns. Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed. RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space. Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)
      - Permik 3mo ago
        By the time you have an out-of-order core You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state. Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"

fluffybucktsnek 3mo ago

> Of course not because that's impossible to prove. Why?

hyperhello 3mo ago
It's supposed to be impossible to prove a negative. But it might still happen some day. We just don't know.
- fluffybucktsnek 3mo ago
  "it's impossible to prove a negative" is a simplification. A negation is just the oppositive of an affirmation. If the affirmation is "there is an element E of an infinite set S that satisfies property P", the negation would be "there is no E in S that satisfy P", which would make proving by enumeration require checking every element of an infinite set, which is impossible. But other forms of proof might be possible. The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.
  - adastra22 3mo ago
    It was a joke I think.
  - inigyou 3mo ago
    Someone might also file a new parent, then apply it against RISC-V. You'd think that wouldn't be allowed to happen, and maybe it isn't, but only an expensive lawsuit will prove it
    - fluffybucktsnek 3mo ago
      Given the nature of the US legal system as based on common law, that applies beyond patents, and may affect ARM and x86 as well. In the end, the real, effective law is the one understood by judges, adjucated in court cases, built on precedents. That being said, I don't expect someone filing a new patent after a RISC-V extension being published to last much longer beyond discovery in most cases, which should keep costs in lower end. Specially so in cases of bad faith.

pavlov 3mo ago

Patents only last 20 years. If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.

jurgenburgen 3mo ago
How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?
- pavlov 3mo ago
  The first version of RISC-V was released in 2010. It was based on work done at Berkeley in the 1980s (RISC versions one to four). One reason that RISC-V has so many optional extensions is that you can trust the core is very likely to be patent-free (because everything in it is documented to be older than 20 years) and just evaluate the extensions you need.

u1hcw9nx 3mo ago

If you iterate trough every concept RISC-V has, you might be able to prove it. The RISC/MIPS concepts date back over 40 years. The base instruction set is intentionally designed with unencumbered, expired, or public-domain architectural concepts. RICV-V microarchitectures and implementations are at much high risk of violating patents. Especially anything that is even slightly high performance. SiFive, Andes , and Alibaba’s T-Head are filing thousands of patents on microarchitectural optimizations and extensions. China's RISC-V patent-sharing alliances and other industry groups are building defensive patent cross-license around their RISC-V-related patents.