Are VID.V indexes byte offsets?
No. VID.V writes the element number i starting from 0; forming byte addresses later requires element width or explicit scaling.
Writes each active element index i to destination integer vector vd, using the current SEW for each index value.
VID.V is the RISC-V V extension element-index generation instruction. For each active body element i, it writes the unsigned element number i to vd[i]; with vm=0 only elements selected by v0.t receive generated indexes, while vm=1 writes indexes to all body elements. Inactive and tail elements follow vma/vta. It reads neither memory nor an ordinary source vector.
Starts from OP-V encoding fields, then shows how VID.V reads no source vector and writes each active lane index into an integer vector.
Teaching context: SEW=32, LMUL=m1, VLEN=4096, VLMAX=128, vstart=0, valid vtype, enabled VS, and ta/ma. Active indexes are zero-extended or truncated to SEW; the largest index here is 63, so no truncation occurs. Masked-off/tail elements may retain old values or become all ones; no definite value is displayed. VL=0 updates no destination elements, including tails; successful execution resets vstart=0. Steps are not processor cycles.
vid.v uses OP-V encoding; the vs1 field is fixed to 10001, and the vs2 field is also fixed to reserved value 00000.
This animation shows only ISA-visible relationships from the official V extension: OP-V field decode, active mask-bit scan within vl, and destination integer-vector writeback. It does not model pipelines, caches, or timing.
VID.V writes each active element index i to vd[i]; masking does not renumber indexes, and masked-off elements follow vma undisturbed or agnostic policy.
32-bit OP-V: opcode=1010111, funct3=010, funct6=010100. vs1=10001 is a fixed selector; vs2=00000, with other values reserved. There is no ordinary source vector.
Active element i receives index i; masking does not renumber it. Zero-extend for wider SEW, or retain the low SEW bits on overflow. This is not a byte offset, and no memory is read.
vd is an integer-vector group at current LMUL; a masked destination cannot overlap v0.
Omit v0.t for vm=1; include it for vm=0. Prestart stays unchanged; inactive/tail elements follow vma/vta. Undisturbed preserves old values; agnostic may preserve them or write all ones. vl=0 or vstart≥vl updates no destination elements, including tails; successful execution resets vstart=0.
V 1.0 supports RV32/RV64; require valid vtype and enabled VS. This model fixes SEW=32, LMUL=m1, VLEN=4096, vstart=0, and ta/ma. Nonzero vstart and index truncation boundaries are outside the animation; steps are not processor cycles.
Assume valid e32,m1, enabled VS, supported formats, VLMAX≥4, and a0=4; vsetvli sets vl=4 and vstart=0. v0.t selects lanes 0, 2, 3; v0 mask=1011 → v1=[0,agnostic,2,3]. Inactive/tail elements follow ma/ta without guaranteed zeros.
Assume valid e32,m1, enabled VS, supported formats, VLMAX≥4, and a0=4; vsetvli sets vl=4 and vstart=0. v0.t selects lanes 0, 2, 3; v0 mask=1011 → v1=[0,agnostic,2,3]. Inactive/tail elements follow ma/ta without guaranteed zeros.
Assume valid e32,m1, enabled VS, supported formats, VLMAX≥4, and a0=4; vsetvli sets vl=4 and vstart=0. v0.t selects lanes 0, 2, 3; v0 mask=1011 → v1=[0,agnostic,2,3]. Inactive/tail elements follow ma/ta without guaranteed zeros.
No. VID.V writes the element number i starting from 0; forming byte addresses later requires element width or explicit scaling.
No. VID.V uses the same OP-V class, but its reserved source field must be 00000 and the assembly syntax has no vs2 source operand.
Zero is not guaranteed. vma=0 preserves old values; vma=1 may preserve them or write all ones. Tails follow vta. At vl=0, no destination elements, including tails, update.