Skip to content

Implement remaining RVV 1.0 instruction families #734

Description

@jserv

After PR #733 landed the bulk of the RISC-V V Vector extension, several V 1.0 instruction families are still unimplemented; the decoder currently rejects them with illegal-instruction. Implement each, with EMUL / overlap / alignment validation matching the existing helpers, plus the corresponding execution path (not just decode wiring):

  • vmv<nr>r.v whole-register move (V 1.0 §16.6) — src/decode_v.c op_100111 case 3. Helpers rvv_whole_reg_load / rvv_whole_reg_store in src/rv32_v_template.c already exist; this op needs its own register-to-register move path with vstart / evl handling per spec.
  • vfmv.s.f / vfmv.f.s scalar-FP move (V 1.0 §16.2) — src/decode_v.c op_010000 cases 1 and 5 (VWFUNARY0 / VRFUNARY0).
  • vzext.vf{2,4,8} / vsext.vf{2,4,8} integer extension (V 1.0 §11.3) — src/decode_v.c op_010010 case 2 (VXUNARY0).
  • vfcvt.* / vfwcvt.* (V 1.0 §13.17, §13.18) and vfncvt.* (§13.19) FP conversions — src/decode_v.c op_010010 case 1 (VFUNARY0); reuse scalar softfloat conversion paths.
  • vfsqrt.v (§13.8), vfrsqrt7.v (§13.9), vfrec7.v (§13.10), vfclass.v (§13.14) — src/decode_v.c op_010011 case 1 (VFUNARY1).

Each should land with smoke coverage in tests/rvv-smoke.S.

Tracked under the umbrella issue #504.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions