Home/Instructions/VFWCVT-RTZ-X-F-V
VFWCVT.RTZ.X.F.V

RISC-V VFWCVT.RTZ.X.F.V Instruction Details

Instruction ManualOPFVV

VFWCVT.RTZ.X.F.V widens each active vs2[i] from an SEW-wide FP value to a 2*SEW-wide signed integer result and writes vd[i].

Instruction Syntax

vfwcvt.rtz.x.f.v vd, vs2, vm
Operand Breakdown
vd: destination vector register group.
vs2/vs1 or scalar source: selected by suffixes such as .vv, .vx, .vi, or .vf.
vm: when present, vm=0 uses v0 as the execution mask and vm=1 is unmasked.
VVector Type ConvertFloating-Point

Instruction Behavior

VFWCVT.RTZ.X.F.V is a RISC-V V-extension VFWCVT widening floating-point/integer conversion instruction with syntax vfwcvt.rtz.x.f.v vd, vs2, vm. It executes only for active elements within vl, uses the current SEW for source elements, and writes 2*SEW-wide destination elements; on the base V FP32/FP64 path, this page animation demonstrates SEW=32 inputs producing 64-bit destination results. The encoding uses OP-V, funct6=010010, funct3=001, and VFUNARY0 vs1 selector 01111. The RTZ form always rounds toward zero, but every vector floating-point instruction still requires a valid frm rounding mode; vm=0 uses v0.t as the execution mask and vm=1 is unmasked.

VFWCVT.RTZ.X.F.V Decode And Execute Animation

Decode the OP-V encoding and execute a VFUNARY0 widening conversion lane by lane: each active lane converts the FP value in vs2[i] to a double-width signed integer.

Instruction input
vfwcvt.rtz.x.f.v
Execution context
LMULm1fixed register-group multiplier
VLEN4096fixed vector-register length (bits)
VLMAX128maximum element count at m1
vstart0prestart elements are outside this animation
FP stateFS enabledFS=Off raises illegal instruction; this animation fixes the architectural state to FS enabled
dest EEW64destination element width
vta/vmata, matail/inactive policy
opcode1010111OP-V major opcode
vs101111VFUNARY0 conversion selector
Encoding fields
0x48879257
31..26
25
24..20
19..15
14..12
11..7
6..0
010010
funct6
0
vm
01000
vs2
01111
vs1/sel
001
funct3
00100
vd
1010111
OP-V
Execution data path

lane 0: widen_trunc_signed(-3.75) -> -3

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
widen_trunc_signed(-3.75)
-3
i=1active
widen_trunc_signed(-2.5)
-2
i=2skip
v0.t=0, not executed
--
i=3active
widen_trunc_signed(-0.25)
0
i=4active
widen_trunc_signed(0.25)
0
i=5active
widen_trunc_signed(1.5)
1
i=6skip
v0.t=0, not executed
--
i=7active
widen_trunc_signed(3.75)
3
source SEW=32 / binary32 -> destination width=64 demo values cover finite FP inputs whose rounded integer result fits this demo's integer range. The RTZ form fixes result rounding toward zero, but frm must still be valid. Selecting reserved frm rejects encoding and execution. NaN, infinity, out-of-range cases, and fflags still follow the official RVV/scalar FP conversion rules; the 64-bit integer demo range avoids JavaScript unsafe-integer edges.

Quick Understanding & Search Notes

VFWCVT.RTZ.X.F.V is best understood as a VFUNARY0 widening conversion: after decoding vs1=01111, active elements convert vs2[i] from an SEW-wide FP value to a 2*SEW-wide signed integer result.

In the OP-V encoding, funct6=010010 and funct3=001 select the vector FP/integer conversion group, and VFUNARY0 vs1=01111 selects VFWCVT.RTZ.X.F.V.
The syntax input contains only vd, vs2, and vm; VL, SEW, frm, v0.t, and element values are execution context.
This is a widening conversion: source elements use the current SEW and destination elements use 2*SEW; the common base-V path is SEW=32 input producing a 64-bit destination result.
This RTZ form always rounds toward zero, but every vector floating-point instruction still requires a valid frm; an invalid frm makes the instruction behavior reserved.
Only active elements within vl execute; vm=0 uses v0.t and vm=1 is unmasked.
Widening instructions obey the official widening register-overlap constraints; this page animation uses an even vd to represent the vd..vd+1 destination group for LMUL=1.
For FP-to-integer conversion, the valid input range is judged after rounding; NaNs, infinities, out-of-range cases, and inexact/invalid flags follow the official RVV and scalar FP conversion rules.
SEW=16 half-precision or BF16-related extension forms are not fully simulated by this page animation and remain governed by the official Zvfh/Zvfhmin/Zvfbf* rules.

Vector Execution Context

When reading VFWCVT.RTZ.X.F.V, do not stop at the mnemonic. Official V-extension semantics also depend on the current vl, vtype, and mask state. The suffix and operand form determine whether sources are vector, scalar, or immediate values.

Check vl first

The current vl determines the number of body elements. Typical code executes vsetvli, vsetivli, or vsetvl before this instruction.

Then check vtype

The current vtype supplies SEW, LMUL, tail policy, and mask policy; these affect element width, register-group size, and inactive/tail destination elements.

Then check vm/v0

For ordinary vector instructions with vm, vm=0 uses v0 as the execution mask and vm=1 is unmasked. A few forms such as VMERGE use v0 as data-selection input.

Official source: RISC-V V Standard Extension for Vector Operations

Common Usage Scenarios

FP results to 64-bit integer vectors

Understand this scenario with real code like «vsetvli t0, a0, e32, m1, ta, ma vfwcvt.rtz.x.f.v v2, v4».

mixed-type vector conversion

Understand this scenario with real code like «vsetvli t0, a0, e32, m1, ta, ma vfwcvt.rtz.x.f.v v2, v4».

numeric paths needing double-width integer results

Understand this scenario with real code like «vsetvli t0, a0, e32, m1, ta, ma vfwcvt.rtz.x.f.v v2, v4».

Pre-Use Checklist

Syntax Check
  • Confirm the current instruction format is OPFVV.
  • Confirm the operand order matches the example.
Semantic Check
  • Ensure the destination register usage is compatible with the calling convention.
  • Confirm this is not the lower-level form of a pseudo-instruction expansion.

Pitfalls / Common Confusions

This is a widening VFWCVT form: the source is SEW and the destination is 2*SEW; do not treat it as single-width VFCVT or narrowing VFNCVT.
The destination register group occupies the wider EMUL result; this LMUL=1 page animation requires an even vd, and any narrow-source overlap must align with the destination group's highest-numbered register.
With vm=0, v0.t selects active elements only; masked-off elements do not produce the conversion result shown by the animation.
For FP-to-integer conversion, the valid domain is judged after rounding; NaNs, infinities, out-of-range cases, invalid, and inexact still follow the official FP conversion rules.
This page animation covers the checkable SEW=32 to 64-bit destination path; SEW=16/Zvfh/Zvfhmin or BF16-related forms remain governed by the official extension rules.

FAQ

How is VFWCVT.RTZ.X.F.V different from VFCVT?

VFWCVT.RTZ.X.F.V is a VFWCVT widening form: the source is SEW and the destination is 2*SEW. Single-width VFCVT uses the current SEW for both source and destination.

Where does VFWCVT.RTZ.X.F.V take its rounding mode from?

The RTZ form always rounds toward zero, but every vector floating-point instruction still requires a valid frm; behavior with an invalid frm is reserved.

How does VFWCVT.RTZ.X.F.V use the mask operand?

With vm=0, only active elements selected by v0.t are converted; vm=1 is unmasked. Inactive and tail elements follow the current vma/vta policy.

Why does this page animation expose only SEW=32?

The animation focuses on the most checkable base-V FP32/FP64 widening path: SEW=32 input and 2*SEW=64 destination. SEW=16 half precision, 8-bit integer-to-binary16, and BF16-related forms are defined by their corresponding official extensions.