Does VFADD.VV use vxrm?
No. Ordinary RVV FP arithmetic uses the floating-point rounding environment frm or the instruction-defined FP rounding rule; vxrm is for fixed-point rounding instructions.
VFADD.VV
RISC-V VFADD.VV Instruction Details
Instruction ManualOPFVVVFADD.VV performs vector-vector FP add on active elements within VL: vd[i] = vs2[i] + vs1[i].
Instruction Syntax
vfadd.vv vd, vs2, vs1, vm
Operand Breakdown
vd and vs2 are SEW-wide vector groups; same-EEW source/destination overlap is allowed. VFADD.VV also reads a SEW-wide vs1 vector, and equal source registers read equal initial values. Unary instructions use the encoded vs1 bits as a fixed selector.
Require V, enabled VS/FS and supported vtype. V supports binary32/64; these instructions at SEW=16 require Zvfh, not Zvfhmin alone. FS=Off raises illegal instruction; with H and V=1, vsstatus.FS/VS must also be enabled.
Active elements satisfy vstart≤i<vl and (vm=1 or v0[i]=1); omitting v0.t means vm=1. Prestart elements are unchanged, and inactive/tail elements follow vma/vta. VL=0 or vstart≥vl leaves the entire destination unchanged; successful completion resets vstart=0. Implementations may reject nonzero vstart values they cannot produce.
Masked vd cannot overlap v0; v0 cannot supply both an EEW=1 mask and SEW data source. Invalid frm use is reserved even without rounding, at VL=0 or vstart≥vl; an illegal-instruction exception is not guaranteed by that rule.
Active elements add vs2[i]+vs1[i] using dynamic frm rounding; only active-element exceptions accrue in fflags, without fixed-point vxrm.
VVector AddFloating-Point
Instruction Behavior
VFADD.VV is an RVV single-width floating-point addition instruction with syntax vfadd.vv vd, vs2, vs1, vm. Each active element uses the current SEW FP format to execute vd[i] = vs2[i] + vs1[i]; The second source comes from vs1[i]. With vm=0, v0.t controls active elements; with vm=1, execution is unmasked. Rounding mode and exception flags follow the official RVV floating-point rules, and fixed-point vxrm does not control these instructions.
VFADD.VV Decode And Execute Animation
Decode the OP-V encoding and execute lane-wise FP addition with the second source from same-lane vs1.
Instruction input
vfadd.vv
Execution context
LMULfixed register-group multiplier
VLENfixed vector-register length (bits)
VLMAXmaximum element count at m1
vstartprestart elements are outside this animation
frmfinite teaching context fixed at RNE; the architectural instruction uses dynamic frm
FP stateFS=Off raises illegal instruction; this animation fixes the architectural state to FS enabled
vta/vmatail/inactive policy
opcodeOP-V major opcode
Encoding fields
0x00861257
31..26
25
24..20
19..15
14..12
11..7
6..0
000000
funct6
0
vm
01000
vs2
01100
vs1
001
funct3
00100
vd
1010111
OP-V
Execution data path
lane 0: 1 + 0.5 -> 1.5
This lane follows the current-step highlight; the remaining lane results appear below.
Step 1 / 15
Read OP-V encoding fields
V-extension FP instructions use the OP-V major opcode, with funct6, source registers, vm, funct3, vd, and opcode fields.
Lane results
Long vectors scroll inside this module without page overflow.
i=0active
1 + 0.5
1.5
i=1active
1.5 + 1
2.5
i=2skip
v0.t=0, not executed
--
i=3active
2.5 + 2
4.5
i=4active
-3 + 2.5
-0.5
i=5active
3.5 + 3
6.5
i=6skip
v0.t=0, not executed
--
i=7active
4.5 + 4
8.5
This finite-add teaching model fixes VLEN=4096, LMUL=m1, vstart=0, and frm=RNE, with VS/FS enabled and the selected SEW supported. Both vector sources use the same SEW; equal source registers require equal initial values. Inputs are represented as binary32, then each active sum rounds under RNE; inactive/tail elements follow ma/ta without a definite displayed value. NaNs, infinities, invalid NaN boxes, overflow, and fflags are outside this model; the real instruction handles these legal FP conditions using dynamic frm and the official exception rules.
Quick Understanding & Search Notes
VFADD.VV is best understood through OP-V encoding, the same-lane vs1 element, v0.t masking, and per-element vd[i] = vs2[i] + vs1[i].
funct6=000000, funct3=001, and opcode=1010111 identify this OP-V FP arithmetic form.
In vfadd.vv vd, vs2, vs1, vm, vm controls execution masking; vm=0 uses v0.t and vm=1 is unmasked.
For `.vv` forms, each lane reads vs2[i] and vs1[i]; this is not a reduction or cross-lane operation.
Results, NaNs, infinities, rounding, and fflags follow the official vector floating-point rules.
Vector Execution Context
vd and vs2 are SEW-wide vector groups; same-EEW source/destination overlap is allowed. VFADD.VV also reads a SEW-wide vs1 vector, and equal source registers read equal initial values. Unary instructions use the encoded vs1 bits as a fixed selector.
Require V, enabled VS/FS and supported vtype. V supports binary32/64; these instructions at SEW=16 require Zvfh, not Zvfhmin alone. FS=Off raises illegal instruction; with H and V=1, vsstatus.FS/VS must also be enabled.
Active elements satisfy vstart≤i<vl and (vm=1 or v0[i]=1); omitting v0.t means vm=1. Prestart elements are unchanged, and inactive/tail elements follow vma/vta. VL=0 or vstart≥vl leaves the entire destination unchanged; successful completion resets vstart=0. Implementations may reject nonzero vstart values they cannot produce.
Masked vd cannot overlap v0; v0 cannot supply both an EEW=1 mask and SEW data source. Invalid frm use is reserved even without rounding, at VL=0 or vstart≥vl; an illegal-instruction exception is not guaranteed by that rule.
Active elements add vs2[i]+vs1[i] using dynamic frm rounding; only active-element exceptions accrue in fflags, without fixed-point vxrm.
Common Usage Scenarios
Scientific Computing
Assume V/VS/FS enabled, frm=RNE, vstart=0, supported e32,m1, VLMAX≥4 and a0=4. The example is unmasked, so all four body elements execute. Initial values and results: v2=[1,2,-3,4.5], v3=[0.5,-1,3,1.5] → v1=[1.5,1,0,6]. Conversion results use the destination integer/FP type; tails follow ta without assumed zeroing.
Vector Float Ops
Assume V/VS/FS enabled, frm=RNE, vstart=0, supported e32,m1, VLMAX≥4 and a0=4. The example is unmasked, so all four body elements execute. Initial values and results: v2=[1,2,-3,4.5], v3=[0.5,-1,3,1.5] → v1=[1.5,1,0,6]. Conversion results use the destination integer/FP type; tails follow ta without assumed zeroing.
Pre-Use Checklist
Syntax Check
- vd and vs2 are SEW-wide vector groups; same-EEW source/destination overlap is allowed. VFADD.VV also reads a SEW-wide vs1 vector, and equal source registers read equal initial values. Unary instructions use the encoded vs1 bits as a fixed selector.
- Require V, enabled VS/FS and supported vtype. V supports binary32/64; these instructions at SEW=16 require Zvfh, not Zvfhmin alone. FS=Off raises illegal instruction; with H and V=1, vsstatus.FS/VS must also be enabled.
Semantic Check
- Active elements satisfy vstart≤i<vl and (vm=1 or v0[i]=1); omitting v0.t means vm=1. Prestart elements are unchanged, and inactive/tail elements follow vma/vta. VL=0 or vstart≥vl leaves the entire destination unchanged; successful completion resets vstart=0. Implementations may reject nonzero vstart values they cannot produce.
- Masked vd cannot overlap v0; v0 cannot supply both an EEW=1 mask and SEW data source. Invalid frm use is reserved even without rounding, at VL=0 or vstart≥vl; an illegal-instruction exception is not guaranteed by that rule.
- Active elements add vs2[i]+vs1[i] using dynamic frm rounding; only active-element exceptions accrue in fflags, without fixed-point vxrm.
Pitfalls / Common Confusions
The second source comes from vs1[i].
Only elements within VL whose execution mask is true execute; inactive and tail elements follow the current vma/vta policy.
Ordinary RVV FP arithmetic uses the floating-point rounding environment frm / dynamic rounding semantics, not fixed-point vxrm.
Do not treat finite demo values in the browser animation as a full IEEE 754 exception simulator; NaN, infinity, and fflags follow the official manual.
FAQ
What does the vm operand mean for VFADD.VV?
vm=0 uses v0.t as the execution mask; vm=1 is unmasked. It is not an ordinary data source register.