brucehoult
commented
3 years ago Of course it's very useful if particular features can be shown to have been patented or published >20 years ago, but we also need to have a strategy for dealing with novelties.
An example from another extension is that the BitManip GREV instruction seems to have been written about before (but I don't think it was a long as 20 years ago) but never before implemented. GORC on the other hand -- which I invented to reuse the GREV switching network to (as one very useful special case) efficiently detect null bytes terminating C strings -- seems to be entirely novel.
I do agree that we should find and document heritage where it exists, so that we know what is not heritage.
RVI was extensively analysed to show the lineage of its instructions.
RVV has a heritage in Cray and IBM vector machines.
However, RVV has introduced unusual and distinct characteristics that cannot be traced back to such machines, and thus have less clear history. In particular the full nature of the "opcode" is contained not only explicitly in the fetched instruction, and not completed implicitly in the environment, but also explicitly in CSR vtype. Operand addressability and size are determined directly and indirectly by vlmul and vsew (ESEW). Functionality is determined [in part] by vma and vta and CSR vxrm. There is certainly precedent, RISCV CSR frm provides the float rounding modes, and such user settable codes dates back decades. DEC Alpha FPCR for example, back to 1992.
A clear lineage that dates back more than 20 years would be helpful to ensure claims of infringement of others Intellectual Property could be avoided.
RISCV did this for RVI, and that contributed to its acceptance. If we do the same for RVV I believe it will contribute to its success.