Are single-operand instructions R or I-type?
Closed this issue · 3 comments
<Moved from originally misposting in #1257>
In the unpriv-isa-asciidoc_20240411, page 554 or page 563 defines R-type and I-type formats, which differ only in that instr[31:20] = {funct7, rs2} for R-type and imm12 for I-type.
Many instructions such as fsqrt, fcvt, cpop, and zip use a single register, and contain constants in the instr[24:20] that serve as an extended function code rather than an immediate. It appears that the unprivileged spec is silent about their type. Is there a collective understanding of type for these instructions?
Is it best to classify these instructions as I-type even though the immediate is not used as a source operand? Or better to call them R-type with rs2 hardwired to a funct5 value?
Sorry this question is pendantic, but I’m a pedant.
Thank you,
David
Andrew Waterman replied:
...But I’ll briefly comment that I-type would also have been a poor classification because there’s no immediate operand. We use instruction types as classification tools, not as strictures. We’d have several dozen distinct types if we used that tool with precision—-and at that point, it wouldn’t be doing anyone any service.
The reason I'm asking is that I've been preparing a RISC-V quick reference summary table similar to the old MIPS green card. Classifying instruction types helps provide a dense layout. It doesn't need perfect precision because it is quick reference, not an ISA spec.
The following instructions have one register source and no immediate, and I will classify them either as R or I type for the sake of the table. It's the only classification issue common enough to present an issue for the table. I'd prefer to follow a convention if there is any consensus in the community; otherwise I'll make a somewhat arbitrary choice between two imperfect options for the sake of a dense table.
F extension fsqrt, fclass, fcvt, fmv
Zb* extension orc.b, zext, clz{w}, ctz{w}, cpop{w}, sext, rev8
A extension lr
Zfa Extension fli. fround{nx}, fmvh, fcvtmod
Zbk*/Zkn* brev8, zip, unzip, aes64im, sha256*, sha512{sig/sum}{0/1}
After rereading Andrew's answer that he doesn't like I-type classification, I think I'll call these instructions R-type with rs2 tied to a constant, and close the issue.
Just to be clear, I don't think calling them I-type is more inaccurate than calling them R-type--and if you're of the mindset that the register specifiers are the most important feature being classified, calling them I-type might indeed be preferable. (By contrast, the argument for classifying fcvt and fadd together is that we use bits 31..25 in the same manner for both kinds of instruction, and depending on the value of that field, we know that we can use rs2 as an ancillary opcode field.) The best choice probably depends on the pedagogical intent.