Home/Instructions/FCVT.Q.LU
FCVT.Q.LU

RISC-V FCVT.Q.LU Instruction Details

Instruction ManualR-type

Convert unsigned 64-bit int to quad FP [RV64]. R-type, fmt=Q(11), rs2=source LU(11).

Instruction Syntax

fcvt.q.lu rd, rs1[, rm]

rd is FP f0–f31, including writable f0; rs1 is integer x0–x31, with x0 always reading 0. rs2 selects the source type; no immediate.

32-bit OP-FP: funct5=11010, fmt=11 (destination Q), rs2=00011, opcode=1010011.

RV64 only Q; Q depends on D, which depends on F. Enable required extensions and FP state. Finite conversion is exact and legal rm leaves the value unchanged.

Optional assembly rm defaults to dyn, using frm; software should select rne (000). Static rm=101/110 and dynamic frm=101–111 have reserved behavior even for exact conversions.

Interpret the 64 source bits as the selected signed/unsigned type, without FP NaN-boxing checks.

The Q result fills FLEN=128. Exceptions accrue in fflags; exact finite examples set no new flags and do not clear existing flags. Steps are teaching views.

QFloating-Point Convert

Instruction Behavior

fcvt.q.lu converts an unsigned 64-bit integer source to a quad-precision floating-point result. The conversion is exact; software should encode rm as RNE (000), while implementations still process legal and reserved rm encodings as usual.

FCVT.Q.LU Decode And Execute Animation

Shows the Q-extension FCVT flow: decode OP-FP fields, fmt/rs2 conversion selection, the rm rounding field, read the integer source, then write the floating-point destination.

rd
rs1
rm
fcvt.q.lu
,
,

Leave rm empty for the assembly default dyn (111); this DYN example fixes frm=RNE. Use lowercase rne/rtz/rdn/rup/rmm/dyn only.

Execution Context
fmt=Q (11)
rs2=LU
rounding: RNE nearest-even
fflags: 0
RV64-only

Assume required extensions and FP state are enabled, applicable source NaN-boxing is valid, and initial fflags=0. Results preview the current input; Writeback represents commit.

31..27
26..25
24..20
19..15
14..12
11..7
6..0
11010
FCVT.Q
11
fmt=Q
00011
rs2=LU
01011
rs1
000
rm
01010
rd
1010011
OP-FP
Execution Data Path
instruction
0xD6358553
opcode
1010011 -> OP-FP
funct5/fmt
11010 + 11 -> FCVT.Q.LU
rs2
00011 -> LU source
rm
000 -> RNE nearest-even
rd/rs1
fa0(f10) / a1(x11)
read
a1(x11) = 4097
convert
uint64 4097 -> Q 4097
write
fa0(f10) = 4097; 0
Current Step

Fetch: show the 32-bit OP-FP encoding

The word is split as an R-type OP-FP instruction; FCVT uses opcode 1010011.

encoding: 0xD6358553
syntax : fcvt.q.lu fa0(f10), a1(x11), rne
result : fa0(f10) = 4097; 0

The current 64-bit integer example is exactly representable as Q format, so example fflags remains 0.

FCVT Conversion View
LU source
4097
conversion
uint64 4097 -> Q 4097
writeback
fa0(f10) = 4097

The current 64-bit integer example is exactly representable as Q format, so example fflags remains 0.

This animation shows only Q-extension FCVT ISA-visible encoding, source/destination register direction, rounding field, and example fflags; it does not model FPU pipelines, exception handling, NaN payloads, or microarchitecture.

Quick Understanding & Search Notes

fcvt.q.lu converts an unsigned 64-bit integer source to a quad-precision floating-point result. The conversion is exact; software should encode rm as RNE (000), while implementations still process legal and reserved rm encodings as usual.

32-bit OP-FP: funct5=11010, fmt=11, rs2=00011, opcode=1010011; no immediate.
rd is FP f0–f31; rs1 is integer x0–x31; x0 always reads as 0.
RV64 Q only; Q depends on D, which depends on F. Enable required extensions and FP state.
Finite source conversion is exact and legal rm does not change the value. Optional rm defaults to dyn, using frm. Software should select rne (000); static 101/110 and dynamic frm=101–111 have reserved behavior.
Integer sources have no NaN-boxing check; the Q result fills FLEN=128.
Exception flags accrue in fflags; exact finite examples set no new flags, and this instruction does not clear existing flags.

Common Usage Scenarios

Numeric integer-to-floating-point conversion

Understand this scenario with real code like «# x10 = 4097; initial fflags = 0; RV64 fcvt.q.lu f0, x10, rne # f0 = 4097 exactly; fflags = 0».

Pre-Use Checklist

Syntax Check
  • rd is FP f0–f31, including writable f0; rs1 is integer x0–x31, with x0 always reading 0. rs2 selects the source type; no immediate.
  • 32-bit OP-FP: funct5=11010, fmt=11 (destination Q), rs2=00011, opcode=1010011.
Semantic Check
  • RV64 only Q; Q depends on D, which depends on F. Enable required extensions and FP state. Finite conversion is exact and legal rm leaves the value unchanged.
  • Optional assembly rm defaults to dyn, using frm; software should select rne (000). Static rm=101/110 and dynamic frm=101–111 have reserved behavior even for exact conversions.
  • Interpret the 64 source bits as the selected signed/unsigned type, without FP NaN-boxing checks.
  • The Q result fills FLEN=128. Exceptions accrue in fflags; exact finite examples set no new flags and do not clear existing flags. Steps are teaching views.

Pitfalls / Common Confusions

L/LU 64-bit integer source forms are RV64-only.
The integer source operand comes from x[rs1], not a floating-point register, so there is no source NaN-boxing requirement.
The Q extension sets FLEN to 128 bits, so the quad-precision result is written directly to the destination FP register.

FAQ

When does rm matter for fcvt.q.lu?

Every source integer is exactly representable in Q, so legal rm does not change the value. Decode rm normally: software should select rne; omission defaults to dyn, using frm, and reserved encodings retain reserved behavior.

How does fcvt.q.lu differ from related FCVT instructions?

It differs by source/destination format, integer signedness, RV64 restrictions, and whether rounding or invalid conversion can occur.