riscvarchive / riscv-v-spec

Working draft of the proposed RISC-V V vector extension
https://jira.riscv.org/browse/RVG-122
Creative Commons Attribution 4.0 International
963 stars 273 forks source link

instruction format names #93

Open jim-wilson opened 5 years ago

jim-wilson commented 5 years ago

The base ISA gives a 1 to 3 letter name for every instruction format. This is used by the assembler .insn pseudo-op to let one construct new encodings. It would be nice if the vector extension did the same.

For the load/store/amo instructions, I could use the name in the vector instruction formats section without the *, so I'd have VL, VLS, VLX, VS, VSS, VSX, and VAMO instruction types. That is more formats than I actually need though. And for the alu instructions there is no obvious name given. OP-V is the opcode name not the instruction format name. OPIVV etc are funct3 field names.

On a related matter, there is a OPCFG which is only mentioned in the Vector Arithmetic Instruction encoding section, even though there are no arithmetic instructions using it. Both the instruction format section and the configuration instruction section don't mention it. They just mention vsetvli and vsetvl instead of OPCFG.

kasanovic commented 4 years ago

How about: funct3 name(s) -> format name // description OPIVV/OPMVV/OPFVV -> VAVV // vector arithmetic vector-vector OPIVI -> VAVI // vector arithmetic vector-immediate OPIVX/OPFVF/OPMVX -> VAVS // vector arithmetic vector-scalar OPCFG -> VCFG // vector config

Is it important to give formats that target either vd or rd different names?

jim-wilson commented 4 years ago

The assembler will search a list of candidates to find a match, and the intent to allow people to define their own instructions means people should be able to substitute a vd dest where rd is usually expected and vice versa. So we shouldn't need different instruction format names unless fields change size and/or location.

Nelson1225 commented 4 years ago

Dear Krste and Jim,

Thanks for your help and description :)

I'm wondering that if we need to support the much detailed vector instruction names. It would be convenient for user to extend their vector instructions if we can support more flexible vector instruction names. Take vector arithmetic Instructions for example.

[Opcode 0x57 is reserved] OPIVV, opcode, vd, funct3, vs1, vs2, vm, funct6 OPFVV, opcode, vd/rd, funct3, vs1, vs2, vm, funct6 OPMVV, opcode, vd/rd, funct3, vs1, vs2, vm, funct6 OPIVI, opcode, vd, funct3, simm5, vs2, vm, funct6 OPFVF, opcode, vd, funct3, rs1, vs2, vm, funct6 OPMVX, opcode, vd/rd, funct3, rs1, vs2, vm, funct6

Thanks for Krste's suggestion, we have four instruction names now, VAVV, opcode, vd/rd, funct3, vs1, vs2, vm, funct6 VAVS, opcode, vd/rd, funct3, rs1, vs2, vm, funct6 VAVI, opcode, vd, 0x3, simm5, vs2, vm, func6 VCFG, opcode, rd, 0x7, rs1, imm11, [0|1]

What I meant to say is that VAVV and VAVS seems be the same format if we regard them as the vector instructions which use three registers. And their fields have the same location and size. I agree with Jim's suggestion, "we shouldn't need different instruction format names unless fields change size and/or location". So maybe we can merge the VAVV and VAVS to the one format:

(The instruction names are only temporary) (Rn means Vector Register/GPR/FPR, n = 1, 2, 3) VAV, opcode, R1, funct3, R2, R3, vm, funct6 VAVI, opcode, R1, funct3, simm5, R3, vm, funct6 VCFG, opcode, R1, funct3, R2, zimm11, [0|1]

Moreover, consider the other vector instructions,

[Opcode 0x7 is LOAD_FP and 0x27 is STORE_FP] VL, opcode, vd, width, rs1, lumop, vm, mop, nf VLS, opcode, vd, width, rs1, rs2, vm, mop, nf VLX, opcode, vd, width, rs1, vs2, vm, mop, nf VS, opcode, vs3, width, rs1, sumop, vm, mop, nf VSS, opcode, vs3, width, rs1, rs2, vm, mop, nf VSX, opcode, vs3, width, rs1, vs2, vm, mop, nf

[Opcode 0x2f is AMO] VAMO*, opcode, vd/vs3, width, rs1, vs2, vm, wd, amoop

And likewise the valu, we may need the following vector instruction names, VL/SL -> VMU VLS/VLX/VSS/VSX -> VM VAMO* -> VAMO

VAV, opcode, R1, funct3, R2, R3, vm, funct6 VAVI, opcode, R1, funct3, simm5, R3, vm, funct6 VCFG, opcode, R1, funct3, R2, zimm11, [0|1] VM, opcode, R1, width, R2, R3, vm, mop, nf VMU, opcode, R1, width, R2, [l|s]umop, vm, mop, nf VAMO, opcode, R1, width, R2, R3, vm, wd, amoop

However, there are three combined fields have the same size and location ([vm+funct6], [vm+mop+nf], [vm+wd+amoop]). Therefore, if we regard them as the same combined field, then we just need four instruction names currently. VAV/VM/VAMO -> V3R VAVI -> V2R_VI VCFG -> V2R_CFG VMU -> V2R_MU

Although the simm5 and R2, lumop, sumop and R3 have the same size and positions, regard them as the same field is strange, I have mentioned this in the https://github.com/riscv/riscv-binutils-gdb/pull/184. I think we can probably reference the GNU document for the instruction formats (R-type and R4-type): https://embarc.org/man-pages/as/RISC_002dV_002dFormats.html#RISC_002dV_002dFormats

In addition, I suppose that at least one vector register is used in the vector instruction formats, except the VCFG instructions. Otherwise, user can use the vector formats to describe the general R-type instructions. I'm not sure if this behavior is allowed?

Any suggestion is appreciated :)

Thanks and Regards Nelson