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

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

Instruction ManualR-type

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.
VZvfhVector Type ConvertFloating-Point
Related Search Terms
VFWCVT.RTZ.X.F.V instructionRISC-V VFWCVT.RTZ.X.F.Vvfwcvt.rtz.x.f.v syntaxvfwcvt.rtz.x.f.v encodingRVV VFWCVT widening conversion2*SEW vector conversionvs1=01111FP to signed int

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 and does not read frm; 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.

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.

Instruction input
vfwcvt.rtz.x.f.v
Execution context
rounding
RTZ
instruction-specified; frm validity still applies
dest EEW
64
destination element width
vta/vma
ta, ma
tail/inactive policy
opcode
1010111
OP-V major opcode
vs1
01111
VFUNARY0 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
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's result rounding is fixed by the instruction to round-toward-zero; frm validity still follows the official vector FP rules. 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 and does not read frm.
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.
RISC-V Unprivileged ISA Manual: V extension Widening Floating-Point/Integer Type-Convert InstructionsRISC-V Unprivileged ISA Manual: F extension floating-point conversion and rounding 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 R-type.
  • 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 avoids vd..vd+1 overlap with the source group.
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 and does not use frm.

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.