This repo has no license information.

Seems like fmvp.d.x is not in line with specification. Here is what spec states:

For RV32 only, if the D extension is implemented, the FMVP.D.X instruction moves a double-precision
number from a pair of integer registers into a floating-point register. Integer registers rs1 and rs2
supply bits 31:0 and 63:32, respectively; the result is written to floating-point register rd. FMVP.D.X is
encoded in the OP-FP major opcode with funct3=0 and funct7=1011001

The meaning of the above is that instruction consumes three registers, rs1, rs2 and rd but this is how it is defined in unratified/rv32_d_zfa

fmvp.d.x rd rs1 24..20=1 31..27=0x16 14..12=0 26..25=1 6..2=0x14 1..0=3

From the above it can be oserved that fmvp.d.x consumes rd and rs1 while having rs2=1 which is not in line with spec.

E.g. it mentions what <args> can be but leaves out bimm12hi, pred, succ, aqrl, and jimm20.

This repo clearly has many assumptions about directory layout, etc. It'd be nice to document how to get it up and running; a minimal README would probably suffice.

This may be debatable: the base opcodes table does a reasonable job a naming the individual fields, suchs as rs1, imm12, bimm12lo, jimm20, etc. Enough that you can make a crude disassembler/assembler based on it as long as those fields names are treated correctly.

It seems that the treatment of compressed instructions is significantly different; instead of naming individual fields (and the myrid of immediate encodings) they have all been named ignore.

Wouldn't it be desirable to do the same for compressed as for uncompressed? Eg. instead of

c.lw       1..0=0 15..13=2 12=ignore 11..2=ignore

we could have (untested)

c.lw       15..13=2 c.uimm6hi rs1' c.uimm6lo rd' 1..0=0

(along with the corresponding parse_opcode changes).

The only way to use this is to modify the sources. Two things would improve this:

• refactoring the code into a function so we can import it
• renaming parse-opcodes so it can be a legal module name.

Kindly update parse-opcodes script, if possible. It tries to put encoding.h in the riscv-fesvr directory, whose repo is marked obsolete. Also, it seems encoding.h had been updated in other repos manually, leading to parse-opcodes breaking the previously working builds of the tools.

The following instructions mentioned in spec:

15. Vector Mask Instructions

But missing in opcodes-rvv file

vmmv.m
vmclr.m
vmset.m
vmnot.m

vcpop.m

Hi,

Seems like definitions of Vector Mask-Register Logical Instructions are not up to spec.
Namely, Chapter 15.1 of 1.1-draft Vector spec, says the following:

Vector mask logical instructions are always unmasked, so there are no inactive
elements, and the encodings with vm=0 are reserved.

However, lets take one instruction such as vmand.mm, its definition is as follows
(taken from rv_v file):

vmand.mm 31..26=0x19 vm vs2 vs1 14..12=0x2 vd 6..0=0x57

Here we see it says vm is a varible field, which is not in accordance with spec.

How do we proceed here, should I submit a fix for this?

Thanks

I have been using this repo as the official source of encodings for our internal design and verification tools. One issue that I have been facing is the lack of concrete information of "under which extension(s) is an instruction applicable". I am looking at decoding only instructions which are applicable for a user-defined ISA. So if the user specifies RV64IMC then only instructions under those 3 extensions must be decoded. Even though the filenaming convention right now is somewhat useful, it does not fully address all the issues. two of which I have described below:

1. c.flw should be applicable only when F and C are both implemented. So placing it inside opcodes-rvc confuses the tools and having a separate file opcodes-rv32fc increases maintenance.
2. instructions like pack which are present under multiple extensions (zbp, zbf and zbe). Placing pack into individual opcodes file for each sub-extension might work but is not scalable. One has to remember to edit all those files for any change in the instruction

so, having a file-naming convention alone might not work. The syntax of opcode entries will need to change slightly. The following is a very quick and dirty proposal (and will need refining) of what I think can work to address the above issues:

Add the list of comma-separated extensions under which the encoding is a legal instruction; wrapped within | | at the end of the line.

Examples

c.flw      1..0=0 15..13=3 12=ignore 11..2=ignore |RV32FC|

pack       rd rs1 rs2 31..25=4  14..12=4 6..2=0x0C 1..0=3 |RV32Zbp, RV32Zbf, RV32Zbe, RV64Zbp, RV64Zbf, RV64Zbe|

Tools can then use substring matching to identify if that instruction is applicable for the user-defined ISA or not.

A better way of doing the above would be to use regex (less readable but extremely powerful) :

c.flw      1..0=0 15..13=3 12=ignore 11..2=ignore |RV(32).*(F).*(C).*|

pack       rd rs1 rs2 31..25=4  14..12=4 6..2=0x0C 1..0=3 |RV(32|64).*(Zbp|Zbf|Zbe).*|

The regex will need to follow a few strict guidelines while writing but that should be manageable.

Pros of the proposal:

• the syntax is pretty regex-able and simply adds on to the current syntax. Current tools depending on this repo will simply need to ignore everything between | |.
• minimal changes to existing scripts in this repo to generate the current set of artifacts
• does not require a strict file naming convention - improves scalability
• number of files in the repo will reduce - improves maintenance

Before I go on to work on a PR for the above, I wanted to get a sense if such a change is welcomed/acceptable?

It seems that the information about the position and range of the arguments is not encoded, and this information is clearly described in the specification.

If a downstream program is parsing the instr_dict.yaml file generated by parse.py, how should it correctly get the position and range of each argument for a instruction?

I'm trying to update rocket chip's Instructions.scala since the merge of #106. I found that SLLI_RV32, SRLI_RV32, SRAI_RV32 are not generated. It turns out that rv32_i uses the opcode from rv64_i directly

However, this would cause problem. In RV32 if the decoder is fed slli rd, rs, 32 as encoded below, the result would be slli rd, rs, 0 whereas originally this would cause an illegal instruction exception.

000000100000?????001?????0010011

Cc @neelgala

FYI

SLLI_RV32 = BitPat("b0000000??????????001?????0010011")
SLLI      = BitPat("b000000???????????001?????0010011")

When attempting to turn instr-table.tex and priv-instr-table.tex into PDFs, it just spits out a ton of errors. You can get the logs here: latex-error-logs.zip produced from TeX Studio.

Specs: https://linux-hardware.org/?probe=1146b0ebfc

As far as I can tell, this 'c' doesn't serve any purpose, and actually breaks make install.

make: *** No rule to make target 'c', needed by 'install'.  Stop.

Seems very much like it is, should ideally be merged to a single source of truth and/or the one in this repository should get the same improvements as this? riscv-software-src/riscv-config#105

The following instructions mentioned in spec:

11.8. Vector Integer Comparison Instructions

But missing in opcodes-rvv file

vmsgeu.vx 
vmsge.vx

The following instructions mentioned in spec:

14. Vector Reduction Operations

But missing in opcodes-rvv file

vfredusum.vs
vfwredusum.vs

opcodes-system has an encoding for "hfence.vvma" but not hfence.bvma. I'm guessing this is a typo, but figured I'd check before setting up a one-character PR.

The background is in the RocketChip, we need metadatas for instruction decoding, rather than instruction name and bitpat only. For downstreams like us, which need to parse instruction metadata from riscv-opcodes. I think it might be good to change constant.py to parse the constant.json(or some structural text file) to make other projects being able to directly use these constant to generate metadatas.

I am missing these control sequences in the generated tex files. Am I missing a library? Or were these functions forgotten to be included?

#define DEFAULT_RSTVEC     0x00001000
#define CLINT_BASE         0x02000000
#define CLINT_SIZE         0x000c0000
#define EXT_IO_BASE        0x40000000
#define DRAM_BASE          0x80000000

Correct me if I'm wrong, but these are platform specific details and seem like they don't belong in a "canonical" RISC-V definitions file

The parser uses things like masks and matches. From the parsers code, I infer that masks and matches are used for determining what instruction is being (de)coded. I'm writing a RISC-V assembler in Rust that uses this repository to generate all the instruction encoding functions, but I don't know what to set the initial instruction value to (mask or match). How does (en)coding instructions work exactly, assuming I want to use this repository?

Improvement suggestion (merely a note to self):

The integer literals in the generated encoding.out.h C header file should contain ULL suffixes (unsigned long long) when the actual value exceeds 64 bits.

This improvement has been requested in OpenOCD project which utilizes this generated .h file: https://review.openocd.org/c/openocd/+/7600

When using only the rv32_i EXTENSION, the generated masks are only for slli, srai and srli instructions. The rest are all CSR masks. Is this expected? Aren't there several other instructions in the base integer instruction set? The generated LaTeX table has several other instructions. What happened to all of those? Am I missing something?

The following instructions mentioned in spec:

11.4. Vector Integer Add-with-Carry / Subtract-with-Borrow Instructions

But missing in opcodes-rvv file

vmadc.vv
vmadc.vx
vmadc.vi

vmsbc.vv
vmsbc.vx

It'd be useful for new consumers of riscv-opcodes for parse-opcodes to have a standardized output format, such as json, in addition to language-specific generators. That'll keep the core simple; people can write their own generators from json to their language of choice out of the tree.

For bonus points, commit the generated json for the core RISC-V ISA when anything changes. Then folks can just grab the json instead of having to get the repo up and running (see #6).

I should also say: Thanks so much for having this. So much nicer than transcribing opcodes from a PDF. :)

From the README's description of pseudo instructions, I think the extension is complete even if these pseudo instructions are removed. But I found slli instruction in rv32_i file with the $pseudo prefix which I think is not a pseudo instruction. I don't think slli in rv32i and slli in rv64i are related in this situation.

While the individual code generators are useful, it'd be nice to have a machine-readable version-- sometimes the default generators just aren't a fit! instr_dict.yaml almost gets there, but it only includes the instructions and none of the other useful sideband data like csrs or field positions.

To that end, I'd like to propose the following:

• Move the current contents of the yaml file (ie, the raw mapping of instructions) to a subfield called eg. 'instructions'. This is a breaking change, but as far as I can tell, no open source code directly uses instr_dict.yaml.
• Add a format version number to it to track changes
• Start adding other data to get everything from the constants file automatically copied to the yaml file

I'm willing to put in effort here, but is this something the community is interested in?

Hi, I found that the opcodes in above line is [25:20], which should be [24:20] in spec. Is there is a miswrite, or I miss something ?

This repo has been very useful for gathering information about the ISA in a programmatic way. I think one of the shortcomings is that it doesn't contain any information about the instruction format (ex: I, J, U ...). This could be used to programmatically verify that implementations are handling the instructions in a correct manner.

Currently I do this manually by cross-referencing the spec itself. Is there a better way to do this?

mod rd rs1 rs2 31..25=1 14..12=0 6..2=0x1A 1..0=3

I am trying to understand what exactly this sentence means.
I found this line here,
https://nitish2112.github.io/post/adding-instruction-riscv/

what is the purpose of this line?
What is "14..12=0" , "6..2=0x1A" and "1..0=3" ?
What do they do?

If you define a R-Type instruction with the same opcode and funct3 fields as a previously defined I-Type instruction, the parse-opcode script will not recognise the overlapping.

Example opcodes file (named opcodes-fail), that produces the error:

foo1  rd rs1 imm12            14..12=0 6..2=2 1..0=3
bar1  rd rs1 rs2     31..25=1 14..12=0 6..2=2 1..0=3

bar0  rd rs1 rs2     31..25=1 14..12=1 6..2=2 1..0=3
foo0  rd rs1 imm12            14..12=1 6..2=2 1..0=3

Shell command:

 cat opcodes-fail | ./parse-opcodes -c

Output:

foo0 and bar0 overlap

New spec in chaper:

7.4. Vector Unit-Stride Instructions

Has new names for some instructions:

vlm.v
vsm.v

Old names in opcodes-rvv file

vle1.v
vse1.v

The version of encoding.h is not even cloe to up-to-date. It doesn't even have all the CSRs in the ratified priv spec (e.g. PMPCFGx, PMPADDRx). This needs to be regenerated as part of a C/I script whenever something new is added in its dependencies.

I want to combine 2 instructions add and addi. Both of them have different opcodes and funct3 values.

While declaring a new instruction that combines both these instructions in the opcodes file, can I declare the opcode and funct3 values as a result obtained by XORing the opcode and funct3 values of add and addi?

Since the P and V extensions have overlapping functionality, yet are largely suited to different application domains, they are considered mutually incompatible. This avails each extension of the other's major opcode without concern of collision.

As allowed, the proposed Vector Crypto encodings overlap with some of the proposed Packed-SIMD encodings. We are getting conflicts when we run the python script in riscv-opcodes (with crypto opcodes in our own branch):

$ make
Running with args : ['./parse.py', '-c', '-go', '-chisel', '-sverilog', '-rust', '-latex', '-spinalhdl', 'rv*', 'unratified/rv*']
Extensions selected : ['rv*', 'unratified/rv*']
ERROR:: instruction : rstsa16 from rv_p has the same encoding with instruction vsha2ms_vv added from ['rv_zvknh'] in same base extensions
make: *** [Makefile:12: everything] Error 1

Right now both of these extensions are in unratified/rv*, but eventually they will be ratified.

@neelgala We need a means to tell the script which extensions' encodings should be processed and which should be ignored when the opcodes are reused in mutually exclusive extensions.

here, in riscv-opcodes,
Zfa/fround.h is encoded as rd rs1 24..20=4 31..27=0x08 rm 26..25=2 6..2=0x14 1..0=3
Zfbfmin/fcvt.bf16.s is encoded as rd rs1 24..20=8 31..27=0x08 rm 26..25=2 6..2=0x14 1..0=3

However, In the bfloat16 spec,
Zfbfmin/fcvt.bf16.s is encoded as rd rs1 24..20=4 31..27=0x08 rm 26..25=2 6..2=0x14 1..0=3
which is identical and conflicts with fround.h

For fcvt operations, 22..20 are used for the size of the source operand, but in riscv-opcodes [22] is set if the conversion is from/to bfloat16. However, for zfa ops, [22] is an opcode bit for fround/froundnx. Suggestion: change fround/froundnx to be [23:22]=2 instead of [23:22]=1.

The data in riscv-opcodes-master is almost exactly what I need to generate the instruction and operand parsing code for my work on binary code modeling and analysis, except for one thing: both the integer and floating point register fields are named "rs1", "rs2", "rd". The vector register fields are already named "vs1" etc., and if the floating point registers were changed to "fs1" etc., this data would include everything needed for both bit-level parsing and operand identification.

The current README.md does not explain how one would use this repo to add support for new instructions. I assume this repo can somehow be used to generate files useful to Spike and/or binutils?

There is some evidence for this in Spike's git repo:

riscv/encoding.h:/* Automatically generated by parse_opcodes.  */

Currently the README only refers to riscv-tools, which is (1) obsolete, and (2) doesn't seem to actually use this repo for anything. (At least, I couldn't find any script that refers to its riscv-opcodes submodule, or the parse_opcodes script.)

I created a new.h file in the riscv-isa-sim/riscv/insns folder to combine 2 instructions,

addi a5,gp,-1436
add a5,a5,a3

So, the code I wrote to combine these instructions is,

int32_t v0 = sext_xlen(RS1 + insn.i_imm());
WRITE_RD(sext_xlen(v0 + RS1));

When I compiled and ran spike, it crashed.

I think there is something wrong with the logic of my code but I do not know how to fix it.

Hi Sir,
I have some problems.
(1) I can not find some instructions in rvv-opcodes, such as vlseg3e32 and vluxseq3ei32.v, ...
(2) vslideup.vi has a unsigned imm5, but it has simm5 in rvv-opcodes.

Please give confirmation for these problems.

Thanks!

Hello,

For the standard/regular instructions, I think checking for encoding conflict is necessary. Note that only checking encoding conflict for instructions that belong to the same base extension. For example, c_ld and c_flw have the same encoding but no conflict because c_ld only exists on rv64 and c_flw only exists on rv32.

If that is ok, I can submit a patch for that checking.

Currently we have a single file rv_zicbo wich does not correspond to a specific extension group.

Should it be split into 3 files: zicbom, zicboz, zicbop ?

For the compressed shift instructions, shamt[5] is not allowed to be 1 per the spec, and the comment next to the listings say that RV32 NSE, nzuimm[5]=1.
Yet the opcode spec doesn't care about it: https://github.com/riscv/riscv-opcodes/blob/master/opcodes-rvc#L17

Therefore: should there not be RV32-specific versions of these instructions which declare this bit to 0, like done for slli.rv32 and similar?

Priv spec now revers to mtval, etc instead of mbadaddr, but this repo still refers to badaddr.

I was debugging some instruction generation, and came across an issue with the encoding of SLLI/SRLI/SRAI: In the ISA manual the 32-bit variant has a 5-bit shamt encoding, and the bits above (up until bit 30 in the case of SRAI) are required to be 0.
However the 64-bit variant uses 6-bit shamt, and because they are different base ISAs all the other encoding bits are the same as the 32-bit version.

This then causes problems when using the generated opcode mappings, as they allow for 6-bit shamt fields, while the 32-bit ISA forbids shamt[5] to be 1...

There may also be other instructions where this is a problem, is there a plan for tackling this?
It's a bit late to change the base ISA spec now, but one immediate solution (if it wasn't too late) would be to swap the encodings for SLLI/SRLI/SRAI and SLLIW/SRLIW/SRAIW in RV64I, which would then keep the instruction field boundaries concistent...

...which breaks Spike. (If you copy the file into the HEAD of riscv-isa-sim master, you'll see what I mean.)

@neelgala can you resolve this one?

cf. riscv-software-src/riscv-isa-sim#1020

According to: https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#116-vector-single-width-shift-instructions

But in https://github.com/riscv/riscv-opcodes/blob/master/opcodes-rvv
"simm5" is used. I think it should be "zimm5" instead.