6 ms·

I don't know whether anyone has ever really threatened a patent lawsuit over the ISA, but it definitely does seem to be a good idea to document the origins of i

I don't know whether anyone has ever really threatened a patent lawsuit over the ISA, but it definitely does seem to be a good idea to document the origins of instructions, and that they are either so well known and obvious that they can't be patented, or else that they were patented and the patent has expired. Another protection is that the membership application for RISC-V International includes certification that RISC-V does not infringe on the applicant's own patents. With companies such as Intel, AMD, IBM, Marvell, Microchip, MIPS, nVIDIA, NXP, Qualcomm, Renesas, Samsung, Siemens, Sony, STM, Texas Instruments being members that covers a lot of ground. The base ISA (up to RV32GC, RV64GC) very deliberately breaks no new ground. It's just smoother, with known potholes filled in. Many of the optional extensions do break some new ground. The V extension has some unique features, though the basics are inspired by the Cray-1. RVWMO is based on experience gained with ARM and DEC Alpha memory ordering models, but fixing the problems -- and was actually designed by a world-wide group of academic and industry experts. Both of these are examples of something that simply would not be done as well by a small group of people inside a single company, working to a deadline.

_chris_ 3y ago
I believe early on there was a change to a pre-AUIPC instruction due to potential infringement fears (for PC-relative indexing); but everything else was understood to be following well-worn paths.
- brucehoult 3y ago
  Interesting. I hadn't heard that, but then I was a late-comer in 2016 with the user ISA already in its current form. I have some vague memory of having seen something about RISC-V a few years earlier than that, and glancing at the ISA, and not being impressed. But by the time the HiFive1 came it all looked pretty great to me. Not perfect — `SLT[I][U]` should produce 0 or -1 not 0 or 1, for example — but pretty darn good. The C extension also made it vastly more attractive as a practical ISA, and that was a late-comer (even if always "planned" and already mentioned as being developed in the May 2011 spec). Looking at the May 2011 spec (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...) there is `RDNPC Rd` which simply loads next PC into Rd. So that's 4 bytes different to modern `AUIPC Rd,0`, and functionally identical (other than return address predictor SNAFU) to modern `JAL Rd,.+4` or 2011 `JAL .+4` (only `x1` supported). So 32 bit PC-relative addressing needed `RDNPC;LUI;ADD` and then `JALR`/load/store vs modern just `AUIPC` before the main instruction. If there was something before `RDNPC` then it much have been very short-lived! There is allegedly an earlier RISC-V design here... https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-riscv-v2-vcs-dc-v092010a.pdf https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-ris... ... but I get "You don't have permission to access this resource." There is an updated 2011 version which appears to conform to the May 2011 spec. The instruction listing omits load/store byte/half and there is no relative addressing support at all (except `JAL 4`) but that is probably just simplification for a hardware design class. https://inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab2-riscv-v2-vcs-dc.pdf https://inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab2-ris... Chris, do you have access to that fa10 version?
  - _chris_ 3y ago
    I also get a permission error: but I think this (https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-riscv-v2-vcs-dc.pdf https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-ris...) is the same file, and functionally the same as the fa11 version? I think RDNPC is what I was thinking of, but I can't at all remember what was perceived as "risky" about it. I may be overblowing something from memory. AUIPC is better anyways.
    - brucehoult 3y ago
      Ohh .. the ISA changed quite a bit between 2010 and May 2011! - 2010 opcodes left justified like MIPS, 2011 right justified and a func3 like modern RISC-V .. but rd on the far left, not between func3 and opcode. - register names in formats changed from xa, xb, xc (dst) to rs1, rs2, rd - 2010 lw uses xa for dst, sw uses xa for src like MIPS, ARM etc. 2011 has rd always in the same place, with sw using rs2 not rd, like modern RISC-V. - 2010 jalr has no offset, 2011 has 12 bit offset like now. - 2010 the literals for ANDI, ORI, XORI are zero-extended, 2011 unspecified (so I think all sign-ext) - 2010 j/jal have 27 bit offset (28 with shift?), 2011 25 bit field. - 2010 ADD/SUB/shifts have *W suffixes. 2011 is is like modern RV32. - 2010 has SRA / SRAI, 2011 only has logical. Possibly just a simplification for the lab.
      - _chris_ 3y ago
        If you want to do some further archeology, check out the SMIPS ISA, which I believe dates back to 2005 (which itself gradually evolved from the T0/Scale/6.371 MIPS ISAs; and the earliest, T0, was derived from MIPS-II).
        brucehoult 3y ago
        Seems to be just exactly MIPS-II, down to the encoding, but with stuff left out. http://csg.csail.mit.edu/6.S078/6_S078_2012_www/handouts/smipsSpecification.pdf http://csg.csail.mit.edu/6.S078/6_S078_2012_www/handouts/smi...
bsder 3y ago
> RVWMO is based on experience gained with ARM and DEC Alpha memory ordering models, but fixing the problems In what ways? I thought that it was fairly well understood that LR/SC stuff was suboptimal for (for example) lock-free data structures and that the x86 primitives were quite a bit more suitable for those. Taking a superficial look at the RVWMO stuff doesn't seem to contradict this. What am I missing? How was this fixed?
- brucehoult 3y ago
  The memory model and atomic ops are unrelated. The memory model specifies what happens when you DON'T use atomic ops.
ChuckMcM 3y ago
My experience of being in technology companies for > 30 years is that every time something hits "it's everywhere" status people crawl out of the wood works claiming they have both prior art and a patent on it. The entire submarine patent game was about having dozens of unclear patents in the "application" phase, only to sharpen them up and file them as things like RISC-V debut. They become successful and suddenly poof the current patent assignee (typically a law firm) starts chasing around suing people and making people's lives miserable until their patent is invalidated.

_chris_ 3y ago

I believe early on there was a change to a pre-AUIPC instruction due to potential infringement fears (for PC-relative indexing); but everything else was understood to be following well-worn paths.

brucehoult 3y ago
Interesting. I hadn't heard that, but then I was a late-comer in 2016 with the user ISA already in its current form. I have some vague memory of having seen something about RISC-V a few years earlier than that, and glancing at the ISA, and not being impressed. But by the time the HiFive1 came it all looked pretty great to me. Not perfect — `SLT[I][U]` should produce 0 or -1 not 0 or 1, for example — but pretty darn good. The C extension also made it vastly more attractive as a practical ISA, and that was a late-comer (even if always "planned" and already mentioned as being developed in the May 2011 spec). Looking at the May 2011 spec (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-62.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-...) there is `RDNPC Rd` which simply loads next PC into Rd. So that's 4 bytes different to modern `AUIPC Rd,0`, and functionally identical (other than return address predictor SNAFU) to modern `JAL Rd,.+4` or 2011 `JAL .+4` (only `x1` supported). So 32 bit PC-relative addressing needed `RDNPC;LUI;ADD` and then `JALR`/load/store vs modern just `AUIPC` before the main instruction. If there was something before `RDNPC` then it much have been very short-lived! There is allegedly an earlier RISC-V design here... https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-riscv-v2-vcs-dc-v092010a.pdf https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-ris... ... but I get "You don't have permission to access this resource." There is an updated 2011 version which appears to conform to the May 2011 spec. The instruction listing omits load/store byte/half and there is no relative addressing support at all (except `JAL 4`) but that is probably just simplification for a hardware design class. https://inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab2-riscv-v2-vcs-dc.pdf https://inst.eecs.berkeley.edu/~cs250/fa11/handouts/lab2-ris... Chris, do you have access to that fa10 version?
- _chris_ 3y ago
  I also get a permission error: but I think this (https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-riscv-v2-vcs-dc.pdf https://inst.eecs.berkeley.edu/~cs250/fa10/handouts/lab2-ris...) is the same file, and functionally the same as the fa11 version? I think RDNPC is what I was thinking of, but I can't at all remember what was perceived as "risky" about it. I may be overblowing something from memory. AUIPC is better anyways.
  - brucehoult 3y ago
    Ohh .. the ISA changed quite a bit between 2010 and May 2011! - 2010 opcodes left justified like MIPS, 2011 right justified and a func3 like modern RISC-V .. but rd on the far left, not between func3 and opcode. - register names in formats changed from xa, xb, xc (dst) to rs1, rs2, rd - 2010 lw uses xa for dst, sw uses xa for src like MIPS, ARM etc. 2011 has rd always in the same place, with sw using rs2 not rd, like modern RISC-V. - 2010 jalr has no offset, 2011 has 12 bit offset like now. - 2010 the literals for ANDI, ORI, XORI are zero-extended, 2011 unspecified (so I think all sign-ext) - 2010 j/jal have 27 bit offset (28 with shift?), 2011 25 bit field. - 2010 ADD/SUB/shifts have *W suffixes. 2011 is is like modern RV32. - 2010 has SRA / SRAI, 2011 only has logical. Possibly just a simplification for the lab.
    - _chris_ 3y ago
      If you want to do some further archeology, check out the SMIPS ISA, which I believe dates back to 2005 (which itself gradually evolved from the T0/Scale/6.371 MIPS ISAs; and the earliest, T0, was derived from MIPS-II).
      - brucehoult 3y ago
        Seems to be just exactly MIPS-II, down to the encoding, but with stuff left out. http://csg.csail.mit.edu/6.S078/6_S078_2012_www/handouts/smipsSpecification.pdf http://csg.csail.mit.edu/6.S078/6_S078_2012_www/handouts/smi...

bsder 3y ago

> RVWMO is based on experience gained with ARM and DEC Alpha memory ordering models, but fixing the problems In what ways? I thought that it was fairly well understood that LR/SC stuff was suboptimal for (for example) lock-free data structures and that the x86 primitives were quite a bit more suitable for those. Taking a superficial look at the RVWMO stuff doesn't seem to contradict this. What am I missing? How was this fixed?

brucehoult 3y ago
The memory model and atomic ops are unrelated. The memory model specifies what happens when you DON'T use atomic ops.

ChuckMcM 3y ago

My experience of being in technology companies for > 30 years is that every time something hits "it's everywhere" status people crawl out of the wood works claiming they have both prior art and a patent on it. The entire submarine patent game was about having dozens of unclear patents in the "application" phase, only to sharpen them up and file them as things like RISC-V debut. They become successful and suddenly poof the current patent assignee (typically a law firm) starts chasing around suing people and making people's lives miserable until their patent is invalidated.