Missing B Extensions in encoding.h

[IIITM-Jay]

@aswaterman As I was going through the encoding.h file, I observed that B-extensions are not present. It may be probably because the files with prefixes rv32_zb* (e.g., rv32_zbb, rv32_zbs) are having pseudo_op and it is being excluded.

In the parsing logic, the flow of parse.py too ignores pseudo_op .
Is these extensions need not be included in encoding.h ?

[aswaterman]

The B extension is just Zba + Zbb + Zbs, so is it really missing? The contents of rv_zba etc. appear to be complete.

Although it would be desirable to include pseudoinstructions in encoding.h, we need to contend with name collisions. For example, jal is both a real instruction and a pseudoinstruction. (I don't think we have any cases where we have a 3-way collision, so maybe just prepending the instruction with PSEUDO_ would suffice...? e.g. MATCH_PSEUDO_JAL, MASK_PSEUDO_JAL. Just a thought; not sure this is the optimal solution.)

[AFOliveira]

As I was going through the encoding.h file, I observed that B-extensions are not present. It may be probably because the files with prefixes rv32_zb* (e.g., rv32_zbb, rv32_zbs) are having pseudo_op and it is being excluded.

I just wanted to point out that this is not true, if you check per example "sh1add", that is present even without pseudo-ops. Additionally, if you do the default make, you will have all instructions(even the pseudo-ops).

In the parsing logic, the flow of parse.py too ignores pseudo_op .

The reason parse.py ignores the pseudo-ops when you don't run the automated make is that only including "go" is setting them on(see https://github.com/riscv/riscv-opcodes/blob/85da0d6a2e5b349f19e57b122abab74073aa44c6/parse.py#L1059C1-L1061C1).
I don't know why this was built this way, but if anyone needs to include those, you can simply activate the pseudo_ops on a downstream fork and you will have all.

[IIITM-Jay]

The B extension is just Zba + Zbb + Zbs, so is it really missing? The contents of rv_zba etc. appear to be complete.

@aswaterman just thinking, if it would be beneficial and adds any value to the existing contents of zbb , when added additional instructions such as rev (bit reversal) and shfl/unshfl (shuffle/unshuffle).

Although it would be desirable to include pseudoinstructions in encoding.h, we need to contend with name collisions.

It would be nicer as in several assembly-level optimizations and macros, pseudo-ops simplify the process of writing instructions.

The reason parse.py ignores the pseudo-ops when you don't run the automated make is that only including "go" is setting them on(see https://github.com/riscv/riscv-opcodes/blob/85da0d6a2e5b349f19e57b122abab74073aa44c6/parse.py#L1059C1-L1061C1).

@AFOliveira , yes, I do see this, that only for "go", the pseudo instructions are being set as true: include_pseudo = True