RISC-V and Floating-Point - by FPRox

What are you optimizing for?

SubscribeSign in

RISC-V and Floating-Point<br>Because Floating-Point Rocks

FPRox<br>May 16, 2026

10

Share

RISC-V support for floating-point arithmetic is a topic we have partially covered in a few previous posts but we felt like it deserves a full overview post of its own.<br>RISC-V base ISA (RV32I or RV64I) does not define any floating-point instructions. RISC-V provides extensions to the base ISA to bring such support for floating-point arithmetic.<br>The map of ratified floating-point ISA extensions (and their dependencies) is presented in the figures below. The first figure presents both scalar and vector ratified floating-point extensions. The listed scalar extensions are built around a dedicated scalar floating-point register file (FRF ).

There exists a mirror set of scalar floating-point extensions operating from the general purpose register file (XRF ). They are listed in the figure below:

What are you optimizing for ? is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Subscribe

RISC-V original FP support: the F extension

RISC-V introduced support for floating-point through the F extension. This extension specifies a new register file (FRF ) with FLEN -bit wide registers, and a set of operations to perform single precision floating-point (and related) operations. It builds on the 2008 revision of the IEEE-754 standard and includes basic operations (addition, subtraction, division/square root, conversions, …), but also the Fused Multiply-Add (FMA) which was not present in the original version of the IEEE-754 standard (1985).<br>RISC-V Architects made the choice of assigning a dedicated register file for floating-point operands and results of floating-point operations. We covered this in a previous post:

RISC-V Register Files<br>FPRox<br>October 18, 2022

Read full story

Compared to a unified integer1/floating-point register file, this choice implies additional cost for supporting Floating-Point as it adds 32 extra registers and the need for dedicated floating-point load/store and data moves between FRF and XRF; at the same time it simplifies register allocation in programs and provide more flexibility to assign architectural storage to floating-point data operands without competing for the same storage resources as the general purpose operations. The separate register files offer an extra layer of flexibility: general purpose register width, XLEN , can differ from floating-point register width, FLEN ; allowing to tune the register size for the actual workload needs. For example RV32 + D requires 32 x 32-bit general purpose architectural registers (well actually “31 x”, since x0 is free) and 32 x 64-bit floating-point registers; similarly RV64 + F requires 31 x 64-bit general purpose registers and 32 x 32-bit floating-point registers: you just pay for what you need.<br>RISC-V natural choice for IEEE 754 Formats

The base floating-point extension to the RISC-V ISA, the F extension, specifies format operations which make implementations compliant with the IEEE 754 standard (in particular its 2008 revision).<br>The IEEE-754 standard is the most widely accepted floating-point arithmetic standards for CPUs, so selecting it appear as a natural choice for RISC-V.<br>You can find a brief history of the IEEE 754 standard(s) in this post:

IEEE-754: THE floating-point standard<br>FPRox<br>November 22, 2025

Read full story

The F extension defines RISC-V support for single-precision format (IEEE-754’s binary32 , sometimes dubbed FP32 ) and an associated of general operations (including conversions from and to integer formats). RISC-V floating-point support is built around IEEE-754 formats.<br>Historically, the second Floating-Point extension is the D extension, bringing scalar support for double precision format (IEEE-754’s binary64 ) and instructions operating on it.<br>A Quadruple Precision (IEEE-754’s binary128 ) extension, dubbed Q , has also been specified. It seems it has seen only limited interest from the RISC-V community and limited adoption.<br>The original set of F, D, Q extensions has since been extended with support for half precision (IEEE 754’s binary16) which was added with the Zfh and Zfhmin instruction set extensions. Zfhmin is a strict subset of Zfh and only contains basic data moves and conversions.<br>Note: One of the rationales behind Zfhmin is that it allows implementaters to chose to only support binary16 as a storage format and not bother with a full scalar support; saving hardware and still allowing computing on half precision datum after a promotion to binary32.

The F extension (scalar support for single precision) is mandated for most of the other floating-point extensions. For example, it is required to enable half precision support (Zfh or Zfhmin ) or vector floating-point support (Zve32f onward).<br>Later in this post, we will cover the IEEE-754 support on the vector side and...