Is vd output-only?
No. In the official definition, vd is the 2*SEW-wide addend and is overwritten by the final result; the animation exposes it as an editable accumulator input.
widening fused multiply-subtract-accumulator: vs1[i] and vs2[i] are SEW-wide multipliers, while wide vd[i] is the 2*SEW addend and result; (vs1[i] * vs2[i]) - vd[i].
Extension condition: V 1.0 on RV32/RV64, with supported FP formats and vtype and enabled VS/FS. Standard V supports the SEW=32-to-binary64 path shown here; this does not imply a supported binary128 result at SEW=64.
VFWMSAC.VV overwrites the wide addend under the official RVV semantics: vs1[i] and vs2[i] are SEW-wide multipliers, while vd[i] is both the 2*SEW-wide input and result. Each active element evaluates (vs1[i] * vs2[i]) - vd[i] with one fused rounding to the wide result format. With vm=0, v0.t controls lane execution; this page's interactive example fixes a checkable SEW=32-to-binary64 path.
Decode the OP-V encoding and execute widening fused multiply-add lane by lane: two SEW=32 multipliers and the 2*SEW=64 wide vd[i] produce one binary64 fused result; the second multiplier is same-lane vs1.
lane 0: fma(1, 0.5, -(0.5)) -> 0
This lane follows the current-step highlight; the remaining lane results appear below.
V-extension FP instructions use the OP-V major opcode, with funct6, source registers, vm, funct3, vd, and opcode fields.
Read vs1[i] and vs2[i] as SEW-wide multipliers, then fuse them with wide vd[i] as (vs1[i] * vs2[i]) - vd[i]; vd[i] is overwritten by the result.
Syntax: vfwmsac.vv vd, vs1, vs2[, v0.t]. 32-bit OP-V: opcode=1010111, funct3=001, funct6=111110. vd is both the wide input and wide result.
Narrow vector sources use EEW=SEW, EMUL=LMUL; vd uses EEW=2×SEW, EMUL=2×LMUL. Groups with EMUL=2/4/8 align to their size; EMUL>8 is reserved. Old vd is also a wide source; narrow multipliers cannot share registers with its source group. Equal narrow sources read equal initial values.
Each active element computes (vs1[i] * vs2[i]) - old vd[i], with no separate product rounding and one fused rounding to the final double-width result. The real instruction uses dynamic frm, not vxrm. Both multipliers are same-index vector elements.
Omitting v0.t means vm=1; including it means vm=0. Only elements with vstart≤i<vl and an enabled mask execute and accrue FP exceptions to fflags. A masked destination cannot include v0; one register cannot be read as both an EEW=1 mask and different-EEW data source.
Prestart elements do not update or raise exceptions; vl=0 or vstart≥vl updates no destination elements, including tails. Other inactive/tail elements follow vma/vta; ta/ma does not guarantee zeros. Successful execution resets vstart=0.
V 1.0 supports RV32/RV64 and depends on F/D. Require supported FP formats, valid vtype, and enabled VS/FS; with H and virtualization V=1, vsstatus.VS/FS must also be enabled. Invalid frm use is reserved even at vl=0. This animation fixes SEW=32, LMUL=m1, VLEN=4096, vstart=0, RNE, ta/ma, and finite inputs; it does not fully simulate NaNs, infinities, or fflags.
Assume enabled V/VS/FS, valid e32,m1, supported formats, frm=RNE, VLMAX≥4, and a0=4; vsetvli sets vl=4 and vstart=0. Omitting v0.t makes this unmasked: old v4/v5(binary64)=[1,2,-3,4], v8(binary32)=[3,-1,2,5], v12(binary32)=[2,4,-2,0] → v4/v5=[5,-6,-1,-4]. Tails follow ta without guaranteed zeros.
No. In the official definition, vd is the 2*SEW-wide addend and is overwritten by the final result; the animation exposes it as an editable accumulator input.