Add sub-types to existing instruction formats

[AFOliveira]

Summary

Track progress on introducing sub-types for our R-, I-, B-, S-, U-type instruction formats to improve clarity, tooling and testing.

Motivation

• Mixed encodings in each format (e.g. immediates vs. hard-coded bits)
• Ambiguous docs some instructions don't match any type
• Coarse tests that can’t target specific bit-patterns

Proposal

1. Add a subtype field to our instruction schema.
2. Example sub-types:
   • R.aqrl — acquire release Rtype
3. Annotate existing instructions.
4. Create test suite to validate schema in UDB

Next Steps

• Create full list in a readable format to ask for reviews

[AFOliveira]

@Unique-Usman can we discuss this topic here from now on? Please comment this so I can assign it to you

[Unique-Usman]

Hi @AFOliveira, Got stuck in college activities. I am back now. I suggest we use this Github thread instead of excel. People Can also see it and easily drop comment here ? What do you think ?

[AFOliveira]

Hi @AFOliveira, Got stuck in college activities. I am back now. I suggest we use this Github thread instead of excel. People Can also see it and easily drop comment here ? What do you think ?

That's fine, but how? 1000+ lines is not readable as you posted, so maybe you will need to format it in github, which may be a lot of work.

[Unique-Usman]

I think we should use Divide and Conquer approach, I think we should go extension by extension as some of the instruction subtypes are similar across extension. what do you think?

[AFOliveira]

Problem is that won't be easy even for people who may come just to review. Also, the same sub-type may exist in several extensions, but I think it's your call, just try to make it readable, and I'll try to review and ask people to review it

[Unique-Usman]

Yeah, Subtypes exist in different extensions actually. Maybe we can have it in excel. The question is, how do we make it synchronized. For excel, if we have everything inside the excel file, people can come randomly and review. It will be add to know what has been reviewed and what has not been ? If we have in a thread, we can go extension by extension. Have discussion on it, then go to the next extension. If someone comes they can view what has been discussed and proposed. And they can dropped their own idea. Will this be easy to do in excel ?

[Unique-Usman]

This is the sample of what I am saying for example starting with A Extension

A - Extension

R-aq-rl type - suggested type

• Instructions: 20
• Encoding:
  • Match: 00000------------011-----0101111
  • Variables:
    • aq (location: 26)
    • rl (location: 25)
    • rs2 (location: 24-20)
    • rs1 (location: 19-15)
    • rd (location: 11-7)
• Sample Instruction: amomax.w.yaml

R-aq-rl-ls type - suggested type

• Instructions: 2
• Encoding:
  • Match: 00010--00000-----011-----0101111
  • Variables:
    • aq (location: 26)
    • rl (location: 25)
    • rs1 (location: 19-15)
    • rd (location: 11-7)
• Sample Instruction: lr.d.yaml

[Unique-Usman]

We can have people, review the above A extensions and the suggested type. After it has been reviewed, we can now add it to the excel or some other file extension. We can go four extension instead of a single extension for faster review. @AFOliveira what do you think ?

[ThinkOpenly]

As a reference that I find useful, here is a representation of one of the top-level instruction formats supported by the OpenPOWER ISA:

I like how the subtypes are all listed together in a compact table, so you can easily see the differences among them.

@Unique-Usman: pick an extension that has a small to moderate number of subtypes, and within the list of that extensions instructions, pick just one top-level format, say "I-type" or "R-type". Create a table similar to the image above, and let's review that. These tables should probably have a list of associated instructions (from just the one extension) with each row. This information will make the review much easier.

Then we can add, one-by-one, the additional top-level formats covered by that one extension.

Then, we can move, one-by-one, to the other extensions.

How does that sound?

[Unique-Usman]

@ThinkOpenly, that sounds very good. I think we can create the table using the excel format. The question now is where the I post the table for review and discussion here or in the excel format (I do not think this is easier or possible though)?

[AFOliveira]

Github allows the following syntax, but I think you will have to see whatever is easier for you and reviewers

Header 1	Header 2	Header 3
Row 1	Data	More
Row 2	Info	Stuff

[Unique-Usman]

@AFOliveira, that is a good approach. Thanks.

[Unique-Usman]

RISC-V B Extension Instruction Formats

R-type (Suggested-name -> R-default)

Instructions	31-25	24-20	19-15	14-12	11-7	6-0
andn, clmul, clmulh, orn, rol, rolw, ror, rorw, xnor	funct7	rs2	rs1	funct3	rd	opcode

I-type (Suggested-name -> I-shamt-32)

Instructions	31-25	24-20	19-15	14-12	11-7	6-0
rori (RV32), roriw	funct7	shamt[4:0]	rs1	funct3	rd	opcode

I-type (Suggested-name -> I-shamt-64)

Instruction	31-26	25-20	19-15	14-12	11-7	6-0
rori (RV64)	funct6	shamt[5:0]	rs1	funct3	rd	opcode

I-type (I-rev8)

Instructions	31-20	19-15	14-12	11-7	6-0
rev8 (RV32), rev8 (RV64)	imm[11:0]	rs1	funct3	rd	opcode

Above is for B-extension, I am not sure if rev8.yaml is I-type or R-type as I could not find it anywhere. Also, the andn insstructions and other in the first have the same structure as mentioned in the ISA for R-type so, that is why I suggested R-default for them.

[AFOliveira]

Great start! Now, my review:

R-type (Suggested-name -> R-default)

R-type should stay R-type, we do not want to change ratified spec.

I-type (Suggested-name -> I-shamt-32)

I-type (Suggested-name -> I-shamt-64)

Agree with both.

I-type (I-rev8)

Isn't this exactly the ratified I-type? It should stay I-type. Also, this appears in more instructions than just those two, like the register-immediate instructions.

Type:

Register-immediate (rv32):

[Unique-Usman]

Great start! Now, my review:

R-type (Suggested-name -> R-default)

R-type should stay R-type, we do not want to change ratified spec.

Noted. The default should not be changed.

I-type (Suggested-name -> I-shamt-32)

I-type (Suggested-name -> I-shamt-64)

Agree with both.

I-type (I-rev8)

Isn't this exactly the ratified I-type? It should stay I-type. Also, this appears in more instructions than just those two, like the register-immediate instructions.

Yeah, thanks for catching this. I missed it. I will update the script. The default should be default.

[ThinkOpenly]

Above is for B-extension, I am not sure if rev8.yaml is I-type or R-type as I could not find it anywhere. Also, the andn insstructions and other in the first have the same structure as mentioned in the ISA for R-type so, that is why I suggested R-default for them.

Two minor requests/advice for future discussions:

1. I prefer having the list of instruction at the end of the row, this allows the fields in the various tables to roughly line up:

   R-type (Suggested-name -> R-default)

   31-25	24-20	19-15	14-12	11-7	6-0	Instructions
   funct7	rs2	rs1	funct3	rd	opcode	andn, clmul, clmulh, orn, rol, rolw, ror, rorw, xnor

   I-type (Suggested-name -> I-shamt-32)

   31-25	24-20	19-15	14-12	11-7	6-0	Instructions
   funct7	shamt[4:0]	rs1	funct3	rd	opcode	rori (RV32), roriw

2. Put notes/comments associated with one of a list of tables in proximity to the table:

   R-type (Suggested-name -> R-default)

   31-25	24-20	19-15	14-12	11-7	6-0	Instructions
   funct7	rs2	rs1	funct3	rd	opcode	andn, clmul, clmulh, orn, rol, rolw, ror, rorw, xnor

   These instructions have the same structure as mentioned in the ISA for R-type so, that is why I suggested R-default for them.

Great start!

Agreed!

I-type (I-rev8)

Isn't this exactly the ratified I-type?

Are they? They don't use the "imm" field as an immediate value which is used in the instruction operation. Here, it's really another segment in the full opcode. I don't know if there are others like this such that the "I-rev8" is too specific to these instruction encodings. I suggest "I-opcode" for now.

This content was much, much easier to review, so thanks for the extra effort, @Unique-Usman !

Should we create a PR that adds the "subtype" capability to the instruction schema, then we can start merging these "approved" sets of instruction subtype classifications into the database? As long as the "subtype" field isn't made "required", we can begin pushing them in a bit at a time.

[Unique-Usman]

Above is for B-extension, I am not sure if rev8.yaml is I-type or R-type as I could not find it anywhere. Also, the andn insstructions and other in the first have the same structure as mentioned in the ISA for R-type so, that is why I suggested R-default for them.

Two minor requests/advice for future discussions:

1. I prefer having the list of instruction at the end of the row, this allows the fields in the various tables to roughly line up:

2. Put notes/comments associated with one of a list of tables in proximity to the table:

Noted. I will take that into account. Thanks.

I-type (I-rev8)

Isn't this exactly the ratified I-type?

Are they? They don't use the "imm" field as an immediate value which is used in the instruction operation. Here, it's really another segment in the full opcode. I don't know if there are others like this such that the "I-rev8" is too specific to these instruction encodings. I suggest "I-opcode" for now.

There are few other instructions same as I-rev8/I-opcode in other extension. I think I was the one who got it confused. I shouldn't have used imm[11:0] to represent those bit from 31-20. I think we can use const or something. As the byte from 31-20 is constant and already specified. We can call it I-opcode.

Should we create a PR that adds the "subtype" capability to the instruction schema, then we can start merging these "approved" sets of instruction subtype classifications into the database? As long as the "subtype" field isn't made "required", we can begin pushing them in a bit at a time.

A good suggestion.

[ThinkOpenly]

There are few other instructions same as I-rev8/I-opcode in other extension. I think I was the one who got it confused. I shouldn't have used imm[11:0] to represent those bit from 31-20. I think we can use const or something.

Let's call it "opcode2" for now. Or, maybe "funct11" is better, given the way the other similar "funct*" fields are named.

Should we create a PR that adds the "subtype" capability to the instruction schema, then we can start merging these "approved" sets of instruction subtype classifications into the database? As long as the "subtype" field isn't made "required", we can begin pushing them in a bit at a time.

A good suggestion.

@Unique-Usman, are you able to proceed in creating that PR? If so, do let us know if you need any assistance.

[Unique-Usman]

There are few other instructions same as I-rev8/I-opcode in other extension. I think I was the one who got it confused. I shouldn't have used imm[11:0] to represent those bit from 31-20. I think we can use const or something.

Let's call it "opcode2" for now. Or, maybe "funct11" is better, given the way the other similar "funct*" fields are named.

I think funct11 is okay and similar to other similar funct*

@Unique-Usman, are you able to proceed in creating that PR? If so, do let us know if you need any assistance.

Adding something like this

"subtype": {
"type": "string",
"enum": ["I-shamt-32", "I-shamt-64", "I-opcode", "R-type' "I-type" ],
"description": "Classification of the instruction type"
}

after "$source" in the inst_schema.json ?

[dhower-qc]

A few comments:

1. Why "sub-type" instead of "type"? I guess "type" is supposed to be something referenced in the manual (I-type, R-type, ...)? And if we have a "type", then is that something also stored in UDB?

2. Since the subtypes are going to be their own DB object, we'll want to reference them from an instruction. Like so:

File arch/inst/sll.yaml

# ...
encoding:
  RV32:
    subtype: { $ref: inst_subtype/i_shamt_32.yaml# }
# ...

File arch/inst_subtype/i_shamt_32.yaml

# making this up, open for debate
variables:
  shamt:
    location: 24-20
    type: shamt
  rs1:
    location: 19-15
    type: xsrc
  rd:
    location: 11-7
    type: xdest
opcodes:
  funct7:
    location: 31-25
  funct3:
    location: 14-12
  opcode:
    location: 6-0

Thus, for the schema, we need to add the reference to inst_schmea.json (see

riscv-unified-db/schemas/inst_schema.json

Lines 217 to 224 in cd2b7ea

	"type": "object",
	"properties": {
	"$ref": {
	"type": "string",
	"format": "uri-reference",
	"pattern": "^inst/.+\\.yaml#.*$",
	"description": "Ref to an instruction that is using a HINT codepoint(s) of this instruction"
	}

for example) and then create a new schema for subtypes.

[ThinkOpenly]

1. Why "sub-type" instead of "type"? I guess "type" is supposed to be something referenced in the manual (I-type, R-type, ...)? And if we have a "type", then is that something also stored in UDB?

Yes, I was thinking we add two attributes to each instruction: format and subtype, with "format" being the primary classification, as in the spec, so "R", "I", "S", "U", etc. (from chapter 2.2 "Base Instruction Formats").

2. Since the subtypes are going to be their own DB object, we'll want to reference them from an instruction. Like so:

encoding:
  RV32:
    subtype: { $ref: inst_subtype/i_shamt_32.yaml# }

Here, I'd vote for inst_subtype/I/i_shamt_32.yaml. (Putting the major format in the path.)

and then create a new schema for subtypes.

Right... much of which would be copied from the existing schema for instruction fields.

[dhower-qc]

Here, I'd vote for inst_subtype/I/i_shamt_32.yaml. (Putting the major format in the path.)

👍

[Unique-Usman]

Thanks @dhower-qc and @ThinkOpenly. I tried to come up with the update to the schema inst_schema.json but, I think I need to take a closer look into how the schema is being done as I am not that familiar to it.

[AFOliveira]

Thanks @dhower-qc and @ThinkOpenly. I tried to come up with the update to the schema inst_schema.json but, I think I need to take a closer look into how the schema is being done as I am not that familiar to it.

I already did that, don't worry about it, I'll PR it to UDB tomorrow.

[ThinkOpenly]

"Floating-point fused multiply-add instructions require a new standard instruction format. R4-type, instructions specify three source registers (rs1, rs2, and rs3) and a destination register (rd). This format is only used by the floating-point fused multiply-add instructions."

But, in these four instructions, the registers are double precision, do we create a sub type to differentiate between the double precision and the floating point(32) i.e .s or we just call all of them R4-type ?

I suggest we name them differently, since in the previous instructions we did create subtype based on the type of the register.

Really good question! The spec also says:

When multiple floating-point precisions are supported, then valid values of narrower n-bit types, n<FLEN, are represented in the lower n bits of an FLEN-bit NaN value, in a process termed NaN-boxing. The upper bits of a valid NaN-boxed value must be all 1s. Valid NaN-boxed n-bit values therefore appear as negative quiet NaNs (qNaNs) when viewed as any wider m-bit value, n < m ≤ FLEN.

So, the registers are exactly the same registers, but the opcodes for double precision operations will treat the values as double-precision (64-bit) values. Since the registers are the same, all else being equal, there is no need for different subtypes between single-precision and double-precision instructions.

[Unique-Usman]

Oh, so basically, for previous instructions we are making the distinction based on the register type i.e integer or float. Double and float uses the same registers ?

e.g
R-d-fff subtype

1. For rs1 and rs2 are floating point registers and rd is also floating point registers (double)

[dhower-qc]

That's right; integer and FP use different register files, so there is no similarity between x12 and f12. Single and double precision FP use the same register file (f), just view it as holding different data types.

[Unique-Usman]

Hello, Let's continue from where we stopped.

I-type

31-20	19-15	14-12	11-7	6-0	Instructions
imm[11:0]	rs1	funct3	rd	opcode	fld

The rs1 here is integer and the rd is floating point register. Should we call this I-d-fi Subtype ?

S-type

31-25	24-20	19-15	14-12	11-7	6-0	Instructions
imm[11:5]	rs2	rs1	funct3	imm[4:0]	opcode	fsd

The rs1 here is integer and the rs2 is floating point register. Should we call this S-d-fi Subtype ?

[ThinkOpenly]

Remind me, for "I-d-fi":

• "I" is for "I-type"
• "d" is for the "D" extension?
• "fi" is for "float-integer"?

[Unique-Usman]

Remind me, for "I-d-fi":

• "I" is for "I-type"
• "d" is for the "D" extension?
• "fi" is for "float-integer"?

Yeah, I am doing this just to have some sort of semantic meaning for the subtype name but, it is not hard requirement.

[jordancarlin]

Remind me, for "I-d-fi":

• "I" is for "I-type"
• "d" is for the "D" extension?
• "fi" is for "float-integer"?

Maybe I'm missing something, but does that mean instructions from the F/D/Q/Zfh extensions will all be different types? And if so, what's the justification for that? Seems like flw/fld/flq/flh should all be the same type.

[Unique-Usman]

Remind me, for "I-d-fi":

• "I" is for "I-type"
• "d" is for the "D" extension?
• "fi" is for "float-integer"?

Maybe I'm missing something, but does that mean instructions from the F/D/Q/Zfh extensions will all be different types? And if so, what's the justification for that? Seems like flw/fld/flq/flh should all be the same type.

hmm, that is really a good point.

One approach is that we could remove the extension part, I also notice that some instructions do have changes in their extension . Another one is we could leave it but, without semantic meaning or not linked to the extension.

What do you think ?

[ThinkOpenly]

The subtypes are really about the fields and their respective interpretations.

It could be that we crisply define the types in some fashion, and the subtypes become obvious.

I'm picturing a CSV were the fields are laid out [(location, type), (location, type), ...], then you just sort --unique that CSV, and you have a list of all of the subtypes. I'm oversimplifying, of course.

If we focus on the fields, taking the most recent, FLD, as an example:

I-type

31-20	19-15	14-12	11-7	6-0
imm[11:0]	rs1	funct3	rd	opcode

Maybe "I-i-x-f" (Type-field0-field1-field2-..., ignoring the non-variables, unless they don't conform to expectations in some way, like "rounding mode" perhaps)?

• "I" for "I-type"
• "i" for signed immediate
• "x" for general-purpose register
• "f" for floating-point register

For FSD:

S-type

31-25	24-20	19-15	14-12	11-7	6-0
imm[11:5]	rs2	rs1	funct3	imm[4:0]	opcode

Maybe "S-i-f-x"?

• "S" for "S-type"
• "i" for signed immediate
• "f" for floating-point register
• "x" for general-purpose register

[Unique-Usman]

This looks good and I think it is well thought out.

[Unique-Usman]

It means we have to review and rename all the initial subtype in D extension
(not a problem). Do we review and rename all of the extension in B extension also, I want ?

[ThinkOpenly]

Do we review and rename all of the extension in B extension also, I want ?

I vote yes. I feel like we're iterating to get to a good solution, and this is expected with a task this large. Thanks for sticking with it!

[AFOliveira]

Sorry for being late, but I agree with the new naming, seems like a reasonable step!

[dhower-qc]

+1 from me

[Unique-Usman]

My suggestion for B extension.

RISC-V B Extension Instruction Formats

It is already R-type

31-25	24-20	19-15	14-12	11-7	6-0	Instructions
funct7	rs2	rs1	funct3	rd	opcode	andn, clmul, clmulh, orn, rol, rolw, ror, rorw, xnor

Suggested type -> I-s-x-x-32

31-25	24-20	19-15	14-12	11-7	6-0	Instructions
funct7	shamt[4:0]	rs1	funct3	rd	opcode	rori (RV32), roriw

"I" — It's an immediate-type layout
"s" — A shift amount (shamt[4:0])
"x" — Source register (rs1)
"x" — Destination register (rd)
32

Suggested type -> I-s-x-x-64

31-26	25-20	19-15	14-12	11-7	6-0	Instructions
funct6	shamt[5:0]	rs1	funct3	rd	opcode	rori (RV64)

"I" — It's an immediate-type layout
"s" — A shift amount (shamt[4:0])
"x" — Source register (rs1)
"x" — Destination register (rd)
64

I-x-x

31-20	19-15	14-12	11-7	6-0	Instructions
func11	rs1	funct3	rd	opcode	rev8 (RV32), rev8 (RV64)

"I" — Instruction uses I-type field layout
"x" — Source register (rs1)
"x" — Destination register (rd)

[Unique-Usman]

I am sorry for the late communication, I went back to my country Nigeria for summer holiday. And it was a long and tiring journey.

[AFOliveira]

Don't worry about that @Unique-Usman! Naming seems good to me!

[Unique-Usman]

@ThinkOpenly @dhower-qc @AFOliveira , let also not forget the other issue here #686

[jordancarlin]

I probably should've shared this earlier, but it just occurred to me that this would be a helpful resource.

As part of developing the cvw-arch-verif functional coverage suite, we ended up defining lots of subtypes for our test generator to use. Similar to what you are doing, we needed different types based on the kind of register and the size of the immediates. We generally went with shorter 2-4 character names, but you can probably use the types as a starting point for which instructions go together even if you choose to go with the more verbose descriptive names.

These types can all be found as the second column of our CSV test plans (https://github.com/openhwgroup/cvw-arch-verif/tree/main/testplans). Taking a quick look, we seem to have similar groupings so far just with different names.

[Unique-Usman]

I probably should've shared this earlier, but it just occurred to me that this would be a helpful resource.

As part of developing the cvw-arch-verif functional coverage suite, we ended up defining lots of subtypes for our test generator to use. Similar to what you are doing, we needed different types based on the kind of register and the size of the immediates. We generally went with shorter 2-4 character names, but you can probably use the types as a starting point for which instructions go together even if you choose to go with the more verbose descriptive names.

These types can all be found as the second column of our CSV test plans (https://github.com/openhwgroup/cvw-arch-verif/tree/main/testplans). Taking a quick look, we seem to have similar groupings so far just with different names.

@ThinkOpenly @dhower-qc @AFOliveira, you guys can take a look, it looks interesting and maybe we could use something from there.

[AFOliveira]

I'll be taking a look, thanks @jordancarlin . In the meantime @Unique-Usman, check if all matches to what you are doing, and you may use that a starting point, easing the effort of your task

[dhower-qc]

Thanks @jordancarlin. There is definitely a lot of overlap. I think the general statement is that a type in cvw maps to at least one unique UDB subtype. We are trying to differentiate on a few more properties, which is going to result in a few more splits.

@Unique-Usman, that's definitely a good resource. If you see something in cvw that has two types where we only have one, then we need to split the subtype in UDB.

[Unique-Usman]

Thanks @jordancarlin. There is definitely a lot of overlap. I think the general statement is that a type in cvw maps to at least one unique UDB subtype. We are trying to differentiate on a few more properties, which is going to result in a few more splits.

@Unique-Usman, that's definitely a good resource. If you see something in cvw that has two types where we only have one, then we need to split the subtype in UDB.

Yeah, there are some extension in the cvw not in UDB, e.g there https://github.com/openhwgroup/cvw-arch-verif/blob/main/testplans/Zbkc.csv, which has two instructions and it is gotten from B extension, do we create that also in UDB ?

[AFOliveira]

Zbkc exists in UDB

[Unique-Usman]

Yeah, that is true, it is in the definedBy.

[Unique-Usman]

My suggestion for B extension.

RISC-V B Extension Instruction Formats

It is already R-type

31-25 24-20 19-15 14-12 11-7 6-0 Instructions
funct7 rs2 rs1 funct3 rd opcode andn, clmul, clmulh, orn, rol, rolw, ror, rorw, xnor

Suggested type -> I-s-x-x-32

31-25 24-20 19-15 14-12 11-7 6-0 Instructions
funct7 shamt[4:0] rs1 funct3 rd opcode rori (RV32), roriw
"I" — It's an immediate-type layout "s" — A shift amount (shamt[4:0]) "x" — Source register (rs1) "x" — Destination register (rd) 32

Suggested type -> I-s-x-x-64

31-26 25-20 19-15 14-12 11-7 6-0 Instructions
funct6 shamt[5:0] rs1 funct3 rd opcode rori (RV64)
"I" — It's an immediate-type layout "s" — A shift amount (shamt[4:0]) "x" — Source register (rs1) "x" — Destination register (rd) 64

I-x-x

31-20 19-15 14-12 11-7 6-0 Instructions
func11 rs1 funct3 rd opcode rev8 (RV32), rev8 (RV64)
"I" — Instruction uses I-type field layout "x" — Source register (rs1) "x" — Destination register (rd)

Let's continue from where we stopped. @dhower-qc and @ThinkOpenly, can you take a look at this ?

[dhower-qc]

looks right to me

[Unique-Usman]

Let's move to D extension.

For the first part.

31-25	24-20	19-15	14-12	11-7	6-0	Instructions
funct7	rs2	rs1	funct3	rd	opcode	fsgnjn.d, fltq.d, fle.d, fmvp.d.x, fmaxm.d, feq.d, fminm.d, fmin.d, flt.d, fsgnjx.d, fmax.d, fleq.d, fsgnj.d

1. R-f-f-f subtype

For rs1 and rs2 are floating point registers and rd is also floating point registers (double)

Fsgnjn.d, fmaxm.d, fminm.d, fmin.d, fsgnjx.d, fmax.d, fsgnj.d, fsgnj.d

2. R-f-f-x subtype

For rs1 and rs2 are floating point registers(double) and rd is integer

Fltq.d, fle.d, feq.d, flt.d, fleq.d

3. R-x-x-f subtype

Integer registers rs1 and rs2 and the rd is float (double)

fmvp.d.x

[jordancarlin]

My suggestion for B extension.

RISC-V B Extension Instruction Formats

Suggested type -> I-s-x-x-32

31-25 24-20 19-15 14-12 11-7 6-0 Instructions
funct7 shamt[4:0] rs1 funct3 rd opcode rori (RV32), roriw
"I" — It's an immediate-type layout "s" — A shift amount (shamt[4:0]) "x" — Source register (rs1) "x" — Destination register (rd) 32

Suggested type -> I-s-x-x-64

31-26 25-20 19-15 14-12 11-7 6-0 Instructions
funct6 shamt[5:0] rs1 funct3 rd opcode rori (RV64)
"I" — It's an immediate-type layout "s" — A shift amount (shamt[5:0]) "x" — Source register (rs1) "x" — Destination register (rd) 64

Should we put the 32/64 next to the s to indicate that it is specifically a max shift amount that is 32/64 and not an instruction for rv32/rv64? So something like I-s32-x-x and I-s64-x-x. Could also use 5/6 to indicate the number of bits in the instruction that encode the shift.