When does rm matter for fcvt.q.lu?
It does not matter for the numeric result. The source integer is exactly representable in the destination floating-point format, so rm does not cause rounding.
Convert unsigned 64-bit int to quad FP [RV64]. R-type, fmt=Q(11), rs2=source LU(11).
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.
Shows the Q-extension FCVT flow: decode OP-FP fields, fmt/rs2 conversion selection, an rm=000 encoding example, read the integer source, then write the floating-point destination.
The word is split as an R-type OP-FP instruction; FCVT uses opcode 1010011.
The current 64-bit integer example is exactly representable as Q format, so example fflags remains 0.
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.
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.
Understand this scenario with real code like «fcvt.q.lu f0, x10 # f0 = (quad)(ulong)x10 (RV64)».
Understand this scenario with real code like «fcvt.q.lu f0, x10 # f0 = (quad)(ulong)x10 (RV64)».
It does not matter for the numeric result. The source integer is exactly representable in the destination floating-point format, so rm does not cause rounding.
It differs by source/destination format, integer signedness, RV64 restrictions, and whether rounding or invalid conversion can occur.