Improve RISC-V pseudo-instructions

[James Ball (james-ball-qualcomm)]

Can we add defined pseudo-instructions to riscv-unified-db?

Here's a port of a post by Ved (link):
"ARC discussed a question about the location of pseudo- instructions with respect to the ISA manual and concluded that a list of pseudo-instructions should be included in the ISA manual. A PR is planned."

[Derek Hower (dhower-qc)]

There is a field for adding pseudo instructions to an instruction definition. For example, in add.uw.yaml from the B extension:

https://github.com/riscv-software-src/riscv-unified-db/blob/1ad462fa6166b6c7206ceb8180a5f8ca28aed1be/arch/inst/B/add.uw.yaml#L25-L27

It's not super thought-out, though, and could probably use some tweaking. Getting some more examples of pseudo instructions we want to define would help.

[James Ball (james-ball-qualcomm)]

Maybe we can get a full list from someone with experience with the RISC-V toolchains (like Ana)?

[Derek Hower (dhower-qc)]

Here's an interesting case:

RDCYCLE is a pseudo instruction defined by Zicntr, but it's an alias of csrrs from Zicsr. The current schema that adds the pseudo instruction under the real instruction isn't a great match since csrrs says it belongs to Zicsr, not Zicntr.

A few possibilities:

1. The existing pseudoinstructions field can add a definedBy key, similar to how CSR fields can have their own definedBy that is different than the parent CSR.
2. Pseudo-instructions could get their own definition file.

I'm inclined to prefer 1. since it matches what we're doing for CSRs/CSR fields, but that's not a strong preference.

[James Ball (james-ball-qualcomm)]

Either solution looks good to me.

[Afonso Oliveira (AFOliveira)]

RDCYCLE is a pseudo instruction defined by Zicntr, but it's an alias of csrrs from Zicsr. The current schema that adds the pseudo instruction under the real instruction isn't a great match since csrrs says it belongs to Zicsr, not Zicntr.

Please correct me if I misunderstood all of this, but doesn't this mean that the riscv-opcodes is so far wrong in defining this pseudo-instruction(and many more from what I have checked)? Since the instruction is defined as

$pseudo_op rv_zicsr::csrrs rdcycle rd 19..15=0 31..20=0xC00 14..12=2 6..2=0x1C 1..0=3

inside the rv_zicsr file.

It seems even a bit more tricky than this since there isn't even a rv_zicntr file, while the spec definitely has them as two different extensions:

[Derek Hower (dhower-qc)]

Please correct me if I misunderstood all of this, but doesn't this mean that the riscv-opcodes is so far wrong in defining this pseudo-instruction(and many more from what I have checked)? Since the instruction is defined as

$pseudo_op rv_zicsr::csrrs rdcycle rd 19..15=0 31..20=0xC00 14..12=2 6..2=0x1C 1..0=3

inside the rv_zicsr file.

Yes, I believe riscv-opcodes is incorrect in this case. In general, I've found that there is quite a bit related to Zicsr/Zicntr/Zihpm that is not correct in the spec/riscv-opcodes, etc. Presumably, this is because those extensions were bolted on as an afterthought; originally, everything was defined in the base architecture.

[Adrian Sampson (sampsyo)]

Maybe I am missing something obvious, but it seems like another wrinkle with the current format is that it's not clear what to do with pseudoinstructions that correspond to a sequence of two real instructions. For example, call translates to a sequence of auipc and jalr. So if pseudoinstructions don't get their own file, it is unclear which file call should go in (auipc.yaml or jalr.yaml?).

Perhaps this is an argument for pseudoinstructions getting their own, independent files?

[Afonso Oliveira (AFOliveira)]

Adrian Sampson (@sampsyo) On top of that , sext.b case would add even a little more complexity to it, since it can or can not be a single instruction.

Maybe there is no need for that and back-ends could do that if pseudoinstructions mention those parameters, but Derek Hower (@dhower-qc) or James Ball (@james-ball-qualcomm) should have a better understanding of whether or not that's possible.

Those parameters could be:

pseudoinstruction:
-AlsoDefinedBy: OtherInstruction
-doesNotExistWhen: ExtensionIsActivated

Obviously my naming is awful :) , but I think the point remains.

[Derek Hower (dhower-qc)]

This is also complicated by the fact that some multi-instruction pseduo-instructions don't have a single mapping (e.g., li).

To sum up complications we've uncovered so far:

• Some pseudo-instructions defined in extension A are actually aliases of an instruction in extension B
• Some pseudo-instructions expand to a sequence of multiple instructions
• Some pseudo-instructions are replaced by a real instruction when an extension is implemented
• Some pseudo-instructions expand to one of many mulit-instruction sequences, which could be toolchain or data-dependent

Given this list, I agree with Adrian Sampson (@sampsyo) -- we should start to specify pseudo-instructions in their own file. The question now is how to structure it to capture these complications.

[Afonso Oliveira (AFOliveira)]

Maybe a simple way would be to use the same logic we're using now, but to specify 'original_instructions:' in pseudo-instructions files.

[Afonso Oliveira (AFOliveira)]

As discussed on last meeting, this is the format for pseudoinstruction I got:

# yaml-language-server: $schema=../../../schemas/inst_schema.json

$schema: inst_schema.json#
kind: pseudoinstruction
name: fsrmi
long_name: No synopsis available.
description: |
      No description available.
definedBy: Zicsr
assembly: xd, imm
origin_instruction: csrrwi
encoding:
  match: 000000000010-----101-----1110011
  variables:
  - name: uimm
    location: 19-15
  - name: rd
    location: 11-7
operation(): |
      

I already have all the pseudo-instructions from riscv-opcodes ready, so if you guys agree wih this, I can PR anytime