Does VSE16.V automatically set vl?
No. vl/vtype are set by an earlier vsetvli, vsetivli, or vsetvl; vector loads and stores execute under the current configuration.
VSE16.V
RISC-V VSE16.V Instruction Details
Instruction ManualV-typeStore active 16-bit elements from vs3 to contiguous memory starting at x[rs1].
Instruction Syntax
vse16.v vs3, (rs1)[, v0.t]
Operand Breakdown
vs3 is the EEW=16 source group; rs1 selects the integer base and x0 supplies zero. Syntax: vse16.v vs3, (rs1)[, v0.t].
Omit v0.t for vm=1; include it for vm=0. EEW is encoded in the instruction; EMUL=(EEW/SEW)×LMUL.
Active elements write to x[rs1]+i×2 bytes. Disabled, prestart and tail elements make no writes. Element accesses are unordered; lane animation is not hardware access order.
Require V 1.0, enabled vector state, valid vtype/register groups and writable memory. Body is vstart≤i<vl. vl=0 makes no access; the store does not update vl or vtype.
VVector MemoryVector Store
Instruction Behavior
VSE16.V stores active 16-bit vs3 elements at x[rs1]+i×2 bytes. Only mask-enabled body elements vstart≤i<vl access memory; omitting v0.t is unmasked.
VSE16.V Decode And Execute Animation
Decode the 16-bit unit-stride store, then compute each element address as x[rs1] + i * 2.
Instruction input
vse16.v
Execution context: EEW=16, unit stride=2 bytes, example SEW=16, LMUL=m1, vstart=0 (a nonzero value starts at that element). These are not assembly syntax operands.
Teaching configuration: V 1.0, enabled VS, valid vtype; VLEN=4096, SEW=EEW=16, LMUL=EMUL=m1, vstart=0. Bases are naturally aligned; rs1=x0 supplies zero. Active writes are assumed successful; traps are not modeled. VL=0 makes no memory access; disabled elements and tails do not write memory. Per-element stages are not actual access order or processor cycles; normal completion resets vstart=0.
Encoding fieldsvse16.v / STORE-FP
31..29
nf
000
28
mew
0
27..26
mop
00
25
vm
0
24..20
sumop
00000
19..15
rs1
01010
14..12
width
101
11..7
vd/vs3
01000
6..0
opcode
0100111
Address and data pathaddr[i] = 0x8000 + i * 2
i=0
i=1
i=2
i=3
i=4
i=5
i=6
i=7
i=8
i=9
i=10
i=11
i=12
i=13
i=14
i=15
addr
0x8000
0x8002
0x8004
0x8006
0x8008
0x800a
0x800c
0x800e
0x8010
0x8012
0x8014
0x8016
0x8018
0x801a
0x801c
0x801e
v8
0x0011
0x0022
0x0033
0x0044
0x0055
0x0066
0x0077
0x0088
0x0099
0x00aa
0x00bb
0x00cc
0x00dd
0x00ee
0x00ff
0x0110
active
1
1
0
1
1
1
1
0
1
1
1
1
0
1
1
1
memory write
...
...
-
...
...
...
...
-
...
...
...
...
-
...
...
...
Step 1 / 22
Show vector memory instruction encoding
The animation starts from the 32-bit vector memory encoding and shows the official bit fields: nf, mew, mop, vm, rs2/vs2 or lumop/sumop, width, register fields, and opcode.
Quick Understanding & Search Notes
Active element i writes vs3[i] to x[rs1]+i×2 bytes. vm=0 uses v0.t; vm=1 is unmasked. Disabled elements and tails do not write memory.
EEW=16, address step=2 bytes. 32-bit STORE-FP: opcode=0100111, mew=0, mop=00, nf=000, sumop=00000, width=101.
EMUL=(EEW/SEW)×LMUL must be within 1/8..8 with a legal register group; unsupported EEW encodings are reserved.
vm denotes optional v0.t or omission, not a numeric assembly operand. Masked vs3 cannot also read v0 at the data EEW.
Require V 1.0, enabled vector state and valid vtype. Body is vstart≤i<vl; vl=0 or vstart≥vl makes no memory writes. Successful completion resets vstart=0.
Unit-stride element accesses are unordered. Misaligned elements may transfer or raise address-misaligned exceptions, depending on implementation and memory region.
Vector Execution Context
vs3 is the EEW=16 source group; rs1 selects the integer base and x0 supplies zero. Syntax: vse16.v vs3, (rs1)[, v0.t].
Omit v0.t for vm=1; include it for vm=0. EEW is encoded in the instruction; EMUL=(EEW/SEW)×LMUL.
Active elements write to x[rs1]+i×2 bytes. Disabled, prestart and tail elements make no writes. Element accesses are unordered; lane animation is not hardware access order.
Require V 1.0, enabled vector state, valid vtype/register groups and writable memory. Body is vstart≤i<vl. vl=0 makes no access; the store does not update vl or vtype.
Common Usage Scenarios
Contiguous Array Write
Assume enabled V/VS, valid m1, VLEN=4096, supported widths, vl=4, vstart=0 and initialized sources, and successful writes to selected writable memory. SEW=EEW=16, x10=0x8000, v8=[1,2,3,4], v0.mask[0..3]=1010 → [0x8000]=1, [0x8004]=3. Only lanes 0 and 2 write memory; other addresses are unchanged, without an access-order guarantee. vl=0 updates no destination.
Vectorized Memory Access
Assume enabled V/VS, valid m1, VLEN=4096, supported widths, vl=4, vstart=0 and initialized sources, and successful writes to selected writable memory. SEW=EEW=16, x10=0x8000, v8=[1,2,3,4], v0.mask[0..3]=1010 → [0x8000]=1, [0x8004]=3. Only lanes 0 and 2 write memory; other addresses are unchanged, without an access-order guarantee. vl=0 updates no destination.
Pre-Use Checklist
Syntax Check
- vs3 is the EEW=16 source group; rs1 selects the integer base and x0 supplies zero. Syntax: vse16.v vs3, (rs1)[, v0.t].
- Omit v0.t for vm=1; include it for vm=0. EEW is encoded in the instruction; EMUL=(EEW/SEW)×LMUL.
Semantic Check
- Active elements write to x[rs1]+i×2 bytes. Disabled, prestart and tail elements make no writes. Element accesses are unordered; lane animation is not hardware access order.
- Require V 1.0, enabled vector state, valid vtype/register groups and writable memory. Body is vstart≤i<vl. vl=0 makes no access; the store does not update vl or vtype.
Pitfalls / Common Confusions
The 16 in the mnemonic is memory element width EEW; the address step is 2 bytes.
Unit-stride access uses consecutive addresses; do not treat it as indexed gather/scatter.
Masked-off elements do not perform memory writes, and they do not write zero to memory.
FAQ
How are unit-stride store addresses calculated?
Active element i uses x[rs1] + i * 2 bytes. This is contiguous memory access, not arbitrary gather/scatter.
Do elements disabled by v0.t access memory?
No. With vm=0, a body element whose v0.t bit is 0 does not perform that element's store memory access.