Update rvv implementation to current v0.10.

[Nelson1225]

There are several changes as follows,

1. Renamed instruction names.

   • vncvt.x.x.v to vncvt.x.x.w
   • vfrece7/vfrsqrte7 to vfrec7/vfrsqrt7

2. Added new instructions.

   • mask load/store instructions (vle1, vse1) - means EEW = MEW + WIDTH NF MEW MOP VM LUMOP/RS2 RS1 WIDTH VD opcode 000 - 00 1 01011 xxxxx --- xxxxx 0000111 VLE, EEW = 1 000 - 00 1 01011 xxxxx --- xxxxx 0100111 VSE, EEW = 1

• vsetivli instruction - means zimm 31 30 zimm RS2 RS1/uimm funct3 RD opcode 1 0 00000 xxxxx xxxxx 111 xxxxx 1010111 vsetvl 1 1 ----- ----- xxxxx 111 xxxxx 1010111 vsetivli 0 - ----- ----- xxxxx 111 xxxxx 1010111 vsetvli

3. Removed obsolete instructions.
   • Reserve memory width encodings for EEW>128b.
   • Remove zvediv and zvqmac since they are not part of v1.0.

[Nelson1225]

• mask load/store instructions (vle1, vse1) - means EEW = MEW + WIDTH NF MEW MOP VM LUMOP/RS2 RS1 WIDTH VD opcode 000 - 00 1 01011 xxxxx --- xxxxx 0000111 VLE, EEW = 1 000 - 00 1 01011 xxxxx --- xxxxx 0100111 VSE, EEW = 1

The spec said in the Table 11 that we should use 0+000 when EEW is 8, and use 0+101 when EEW is 16, and so on. But is doesn't say clearly what value to fill when EEW is 1. So I use 0+000 to fill it that same as EEW=8, sine we will use different LUMOP to distinguish them.

• Here is the spec link, https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#added-eew-encoding-to-whole-register-moves-and-loadstores-to-support-microarchitectures-with-internal-data-rearrangement

[jim-wilson]

It would be nice to save this patch. If some of these extensions get readded in the future, we should use the patch we already had rather than try to write the code again from scratch.

The missing width encoding for EEW=1 should be reported as a bug against riscv-v-spec.

I don't see vfabs.v which is a new pseudo instruction (alias). That can be added in a follow on patch though.

Otherwise this looks right to me.

[aswaterman]

I made a PR to the V spec: https://github.com/riscv/riscv-v-spec/pull/645 -- @Nelson1225's guess was correct.

[Nelson1225]

It would be nice to save this patch. If some of these extensions get readded in the future, we should use the patch we already had rather than try to write the code again from scratch.

That's a good idea. I plan to port these stuff based on the 2.36.1 branch, so we can save this patch in this branch, and readd them quickly once we need them in the future.

I don't see vfabs.v which is a new pseudo instruction (alias). That can be added in a follow on patch though.

Oh... I miss this one, I will add it later.

Otherwise this looks right to me.

Thanks!

[Nelson1225]

I made a PR to the V spec: riscv/riscv-v-spec#645 -- @Nelson1225's guess was correct.

Cool! Thanks