rv32_i slli/srli/srai should not pseudo_op from rv64_i about riscv-opcodes HOT 4 CLOSED

@ZenithalHourlyRate even prior to #106 the slli instruction was considered a pseudo op of the RV64 slli instruction (here). I have simply maintained that relationship here.

Right now the parse.py script is not going to dump any pseudo-ops into the code if the original instruction is already present. This is because there are instructions like slli in RV32 which have the same mnemonics as the original instruction in RV64 but vary in encodings. This makes it difficult to create unique entries in the instruction yaml (even some code for that matter) for each instruction.

If you want to build a decoder for rv32 you can use the following command : make EXTENSIONS="rv32* unratified/rv32*" which would generate the correct encoding for the use-case you have defined.

from riscv-opcodes.

If you want to build a decoder for rv32 you can use the following command : make EXTENSIONS="rv32* unratified/rv32*" which would generate the correct encoding for the use-case you have defined.

Thanks for this information! Unfortunately rocket chip uses the same inst.chisel for both RV32 and RV64, so if I want to make rocket chip work I need to generate both file and merge them, which is painful and not maintainable.

Right now the parse.py script is not going to dump any pseudo-ops into the code if the original instruction is already present.

Is it possible that the parse.py script could detect the difference in encoding and generate different entries when output encoding related codes. For mnemonics they could be the same.

from riscv-opcodes.

for both RV32 and RV64, so if I want to make rocket chip work I need to generate both file and merge them, which is painful and not maintainable.

If you are maintaining a single decoder for both RV32 and RV64 , then it would make sense to include the xlen checks in your decoder itself instead of overloading it in the inst.chisel. For example in rocket maybe moving this check inside this class would solve the problem ? This is similar to what spike does when encodings vary based on XLEN - it has further explicit encoding checks based on XLEN.

Is it possible that the parse.py script could detect the difference in encoding and generate different entries when output encoding related codes. For mnemonics they could be the same.

This is achievable but this would affect other artifacts as well - like the latex table generation. The instruction names in those tables will also change to SLLI_RV32_I which is not acceptable by the spec.

from riscv-opcodes.

For example in rocket maybe moving this check inside this class would solve the problem ?

Thanks! I will try to refactor that. Closing this issue now as it is deemed as an API change instead of a bug.

from riscv-opcodes.