\chapter{``F'' Standard Extension for Single-Precision Floating-Point,
Version 2.2}
\label{sec:single-float}

This chapter describes the standard instruction-set extension for
single-precision floating-point, which is named ``F'' and adds
single-precision floating-point computational instructions compliant
with the IEEE 754-2008 arithmetic standard~\cite{ieee754-2008}.
The F extension depends on the ``Zicsr'' extension for control
and status register access.

\section{F Register State}

The F extension adds 32 floating-point registers, {\tt f0}--{\tt f31},
each 32 bits wide, and a floating-point control and status register
{\tt fcsr}, which contains the operating mode and exception status of the
floating-point unit.  This additional state is shown in
Figure~\ref{fprs}.  We use the term FLEN to describe the width of the
floating-point registers in the RISC-V ISA, and FLEN=32 for the F
single-precision floating-point extension.  Most floating-point
instructions operate on values in the floating-point register file.
Floating-point load and store instructions transfer floating-point
values between registers and memory.  Instructions to transfer values
to and from the integer register file are also provided.

\begin{figure}[htbp]
{\footnotesize
\begin{center}
\begin{tabular}{p{2in}}
\instbitrange{FLEN-1}{0}                                    \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f0\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f1\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f2\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f3\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f4\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f5\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f6\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f7\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f8\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ \ f9\ \ \ \ \ }}       \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f10\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f11\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f12\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f13\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f14\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f15\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f16\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f17\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f18\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f19\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f20\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f21\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f22\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f23\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f24\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f25\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f26\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f27\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f28\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f29\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f30\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{\ \ \ f31\ \ \ \ \ }}        \\ \cline{1-1}
\multicolumn{1}{c}{FLEN}                                    \\

\instbitrange{31}{0}                                        \\ \cline{1-1}
\multicolumn{1}{|c|}{\reglabel{fcsr}}                       \\ \cline{1-1}
\multicolumn{1}{c}{32}                                      \\
\end{tabular}
\end{center}
}
\caption{RISC-V standard F extension single-precision floating-point state.}
\label{fprs}
\end{figure}

\begin{commentary}
We considered a unified register file for both integer and
floating-point values as this simplifies software register allocation
and calling conventions, and reduces total user state.  However, a
split organization increases the total number of registers accessible
with a given instruction width, simplifies provision of enough regfile
ports for wide superscalar issue, supports decoupled
floating-point-unit architectures, and simplifies use of internal
floating-point encoding techniques.  Compiler support and calling
conventions for split register file architectures are well understood,
and using dirty bits on floating-point register file state can reduce
context-switch overhead.
\end{commentary}

\clearpage

\section{Floating-Point Control and Status Register}

The floating-point control and status register, {\tt fcsr}, is a RISC-V
control and status register (CSR).  It is a 32-bit read/write register that
selects the dynamic rounding mode for floating-point arithmetic operations and
holds the accrued exception flags, as shown in Figure~\ref{fcsr}.

\begin{figure*}[h]
{\footnotesize
\begin{center}
\begin{tabular}{K@{}E@{}ccccc}
\instbitrange{31}{8} &
\instbitrange{7}{5} &
\instbit{4} &
\instbit{3} &
\instbit{2} &
\instbit{1} &
\instbit{0} \\
\hline
\multicolumn{1}{|c|}{{\em Reserved}} &
\multicolumn{1}{c|}{Rounding Mode ({\tt frm})} &
\multicolumn{5}{c|}{Accrued Exceptions ({\tt fflags})} \\
\hline
\multicolumn{1}{c}{} &
\multicolumn{1}{c|}{} &
\multicolumn{1}{c|}{NV} &
\multicolumn{1}{c|}{DZ} &
\multicolumn{1}{c|}{OF} &
\multicolumn{1}{c|}{UF} &
\multicolumn{1}{c|}{NX} \\
\cline{3-7}
24 & 3 & 1 & 1 & 1 & 1 & 1 \\
\end{tabular}
\end{center}
}
\vspace{-0.1in}
\caption{Floating-point control and status register.}
\label{fcsr}
\end{figure*}

The {\tt fcsr} register can be read and written with the FRCSR and
FSCSR instructions, which are assembler pseudoinstructions built on the
underlying CSR access instructions.  FRCSR reads {\tt fcsr} by copying
it into integer register {\em rd}.  FSCSR swaps the value in {\tt
  fcsr} by copying the original value into integer register {\em rd},
and then writing a new value obtained from integer register {\em rs1}
into {\tt fcsr}.

The fields within the {\tt fcsr} can also be accessed individually
through different CSR addresses, and separate assembler pseudoinstructions are
defined for these accesses.  The FRRM instruction reads the Rounding
Mode field {\tt frm} and copies it into the least-significant three
bits of integer register {\em rd}, with zero in all other bits.  FSRM
swaps the value in {\tt frm} by copying the original value into
integer register {\em rd}, and then writing a new value obtained from
the three least-significant bits of integer register {\em rs1} into
{\tt frm}.  FRFLAGS and FSFLAGS are defined analogously for the
Accrued Exception Flags field {\tt fflags}.

Bits 31--8 of the {\tt fcsr} are reserved for other standard extensions,
including the ``L'' standard extension for decimal floating-point.  If
these extensions are not present, implementations shall ignore writes to
these bits and supply a zero value when read.  Standard software should
preserve the contents of these bits.

Floating-point operations use either a static rounding mode encoded in
the instruction, or a dynamic rounding mode held in {\tt frm}.
Rounding modes are encoded as shown in Table~\ref{rm}.  A value of 111
in the instruction's {\em rm} field selects the dynamic rounding mode
held in {\tt frm}.  The behavior of floating-point instructions that
depend on rounding mode when executed with a reserved rounding mode is
{\em reserved}, including both static reserved rounding modes (101--110) and
dynamic reserved rounding modes (101--111).  Some instructions, including
widening conversions, have the {\em rm} field but are nevertheless
mathematically unaffected by the rounding mode; software should set their
{\em rm} field to RNE (000) but implementations must treat the {\em rm}
field as usual (in particular, with regard to decoding legal vs. reserved
encodings).

\begin{table}[htp]
\begin{small}
\begin{center}
\begin{tabular}{ccl}
\hline
\multicolumn{1}{|c|}{Rounding Mode} &
\multicolumn{1}{c|}{Mnemonic} &
\multicolumn{1}{c|}{Meaning} \\
\hline
\multicolumn{1}{|c|}{000} &
\multicolumn{1}{l|}{RNE} &
\multicolumn{1}{l|}{Round to Nearest, ties to Even}\\
\hline
\multicolumn{1}{|c|}{001} &
\multicolumn{1}{l|}{RTZ} &
\multicolumn{1}{l|}{Round towards Zero}\\
\hline
\multicolumn{1}{|c|}{010} &
\multicolumn{1}{l|}{RDN} &
\multicolumn{1}{l|}{Round Down (towards $-\infty$)}\\
\hline
\multicolumn{1}{|c|}{011} &
\multicolumn{1}{l|}{RUP} &
\multicolumn{1}{l|}{Round Up (towards $+\infty$)}\\
\hline
\multicolumn{1}{|c|}{100} &
\multicolumn{1}{l|}{RMM} &
\multicolumn{1}{l|}{Round to Nearest, ties to Max Magnitude}\\
\hline
\multicolumn{1}{|c|}{101} &
\multicolumn{1}{l|}{} &
\multicolumn{1}{l|}{\em Reserved for future use.}\\
\hline
\multicolumn{1}{|c|}{110} &
\multicolumn{1}{l|}{} &
\multicolumn{1}{l|}{\em Reserved for future use.}\\
\hline
\multicolumn{1}{|c|}{111} &
\multicolumn{1}{l|}{DYN} &
\multicolumn{1}{l|}{In instruction's {\em rm} field, selects dynamic rounding mode;}\\
\multicolumn{1}{|c|}{} &
\multicolumn{1}{l|}{} &
\multicolumn{1}{l|}{In Rounding Mode register, {\em reserved}.}\\
\hline
\end{tabular}
\end{center}
\end{small}
\caption{Rounding mode encoding.}
\label{rm}
\end{table}

\begin{commentary}
The C99 language standard effectively mandates the provision of a
dynamic rounding mode register.  In typical implementations, writes to
the dynamic rounding mode CSR state will serialize the pipeline.
Static rounding modes are used to implement specialized arithmetic
operations that often have to switch frequently between different
rounding modes.

The ratified version of the F spec mandated that an illegal
instruction exception was raised when an instruction was executed with
a reserved dynamic rounding mode.  This has been weakened to reserved,
which matches the behavior of static rounding-mode instructions.
Raising an illegal instruction exception is still valid behavior when
encountering a reserved encoding, so implementations compatible with
the ratified spec are compatible with the weakened spec.
\end{commentary}

The accrued exception flags indicate the exception conditions that
have arisen on any floating-point arithmetic instruction since the
field was last reset by software, as shown in Table~\ref{bitdef}.
The base RISC-V ISA
does not support generating a trap on the setting of a floating-point
exception flag.

\begin{table}[htp]
\begin{small}
\begin{center}
\begin{tabular}{cl}
\hline
\multicolumn{1}{|c|}{Flag Mnemonic} &
\multicolumn{1}{c|}{Flag Meaning} \\
\hline
\multicolumn{1}{|c|}{NV} &
\multicolumn{1}{c|}{Invalid Operation}\\
\hline
\multicolumn{1}{|c|}{DZ} &
\multicolumn{1}{c|}{Divide by Zero}\\
\hline
\multicolumn{1}{|c|}{OF} &
\multicolumn{1}{c|}{Overflow}\\
\hline
\multicolumn{1}{|c|}{UF} &
\multicolumn{1}{c|}{Underflow}\\
\hline
\multicolumn{1}{|c|}{NX} &
\multicolumn{1}{c|}{Inexact}\\
\hline
\end{tabular}
\end{center}
\end{small}
\caption{Accrued exception flag encoding.}
\label{bitdef}
\end{table}

\begin{commentary}
As allowed by the standard, we do not support traps on floating-point
exceptions in the base ISA, but instead require explicit checks of the flags
in software.  We considered adding branches controlled directly by the
contents of the floating-point accrued exception flags, but ultimately chose
to omit these instructions to keep the ISA simple.
\end{commentary}

\section{NaN Generation and Propagation}

Except when otherwise stated, if the result of a floating-point operation is
NaN, it is the canonical NaN.  The canonical NaN has a positive sign and all
significand bits clear except the MSB, a.k.a. the quiet bit.  For
single-precision floating-point, this corresponds to the pattern {\tt
0x7fc00000}.

\begin{commentary}
We considered propagating NaN payloads, as is recommended by the standard,
but this decision would have increased hardware cost.  Moreover, since this
feature is optional in the standard, it cannot be used in portable code.

Implementors are free to provide a NaN payload propagation scheme as
a nonstandard extension enabled by a nonstandard operating mode.  However, the
canonical NaN scheme described above must always be supported and should be
the default mode.
\end{commentary}

\begin{commentary}
We require implementations to return the standard-mandated default
values in the case of exceptional conditions, without any further
intervention on the part of user-level software (unlike the Alpha ISA
floating-point trap barriers).  We believe full hardware handling of
exceptional cases will become more common, and so wish to avoid
complicating the user-level ISA to optimize other approaches.
Implementations can always trap to machine-mode software handlers to
provide exceptional default values.
\end{commentary}

\section{Subnormal Arithmetic}

Operations on subnormal numbers are handled in accordance with the IEEE
754-2008 standard.

In the parlance of the IEEE standard, tininess is detected after rounding.

\begin{commentary}
Detecting tininess after rounding results in fewer spurious underflow signals.
\end{commentary}

\section{Single-Precision Load and Store Instructions}

Floating-point loads and stores use the same base+offset addressing
mode as the integer base ISA, with a base address in register {\em
  rs1} and a 12-bit signed byte offset.  The FLW instruction loads a
single-precision floating-point value from memory into floating-point
register {\em rd}.  FSW stores a single-precision value from
floating-point register {\em rs2} to memory.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{M@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{imm[11:0]} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{width} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
12 & 5 & 3 & 5 & 7 \\
offset[11:0] & base & W & dest & LOAD-FP \\
\end{tabular}
\end{center}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{imm[11:5]} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{width} &
\multicolumn{1}{c|}{imm[4:0]} &
\multicolumn{1}{c|}{opcode} \\
\hline
7 & 5 & 5 & 3 & 5 & 7 \\
offset[11:5] & src & base & W & offset[4:0] & STORE-FP \\
\end{tabular}
\end{center}

FLW and FSW are only guaranteed to execute atomically if the effective address
is naturally aligned.

FLW and FSW do not modify the bits being transferred; in particular, the
payloads of non-canonical NaNs are preserved.

As described in Section~\ref{sec:rv32:ldst}, the EEI defines whether
misaligned floating-point loads and stores are handled invisibly or raise
a contained or fatal trap.

\section{Single-Precision Floating-Point Computational Instructions}
\label{sec:single-float-compute}

Floating-point arithmetic instructions with one or two source operands use the
R-type format with the OP-FP major opcode.  FADD.S and FMUL.S perform
single-precision floating-point addition and multiplication respectively,
between {\em rs1} and {\em rs2}. FSUB.S performs the single-precision
floating-point subtraction of {\em rs2} from {\em rs1}.  FDIV.S performs the
single-precision floating-point division of {\em rs1} by {\em rs2}. FSQRT.S
computes the square root of {\em rs1}.  In each case, the result is written to
{\em rd}.

The 2-bit floating-point format field {\em fmt} is encoded as shown in
Table~\ref{tab:fmt}.  It is set to {\em S} (00) for all instructions in
the F extension.

\begin{table}[htp]
\begin{small}
\begin{center}
\begin{tabular}{|c|c|l|}
\hline
{\em fmt} field &
Mnemonic &
Meaning \\
\hline
00 & S & 32-bit single-precision \\
01 & D & 64-bit double-precision \\
10 & H & 16-bit half-precision \\
11 & Q & 128-bit quad-precision \\
\hline
\end{tabular}
\end{center}
\end{small}
\caption{Format field encoding.}
\label{tab:fmt}
\end{table}

All floating-point operations that perform rounding can select the
rounding mode using the {\em rm} field with the encoding shown in
Table~\ref{rm}.

Floating-point minimum-number and maximum-number instructions FMIN.S and
FMAX.S write, respectively, the smaller or larger of {\em rs1} and {\em rs2}
to {\em rd}.  For the purposes of these instructions only, the value $-0.0$ is
considered to be less than the value $+0.0$.  If both inputs are NaNs, the
result is the canonical NaN.  If only one operand is a NaN, the result is the
non-NaN operand.  Signaling NaN inputs set the invalid operation exception flag,
even when the result is not NaN.

\begin{commentary}
Note that in version 2.2 of the F extension, the FMIN.S and FMAX.S
instructions were amended to implement the proposed IEEE 754-201x
minimumNumber and maximumNumber operations, rather than the IEEE 754-2008
minNum and maxNum operations.  These operations differ in their handling of
signaling NaNs.
\end{commentary}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FADD/FSUB & S & src2 & src1 & RM  & dest & OP-FP  \\
FMUL/FDIV & S & src2 & src1 & RM  & dest & OP-FP  \\
FSQRT     & S & 0    & src  & RM  & dest & OP-FP  \\
FMIN-MAX  & S & src2 & src1 & MIN/MAX & dest & OP-FP  \\
\end{tabular}
\end{center}

Floating-point fused multiply-add instructions require a new standard
instruction format.  R4-type instructions specify three source
registers ({\em rs1}, {\em rs2}, and {\em rs3}) and a destination
register ({\em rd}).  This format is only used by the floating-point
fused multiply-add instructions.

FMADD.S multiplies the values in {\em
rs1} and {\em rs2}, adds the value in {\em rs3}, and writes the final
result to {\em rd}.  FMADD.S computes {\em (rs1$\times$rs2)+rs3}.

FMSUB.S multiplies the values in {\em rs1} and {\em rs2}, subtracts
the value in {\em rs3}, and writes the final result to {\em rd}.
FMSUB.S computes {\em (rs1$\times$rs2)-rs3}.

FNMSUB.S multiplies the
values in {\em rs1} and {\em rs2}, negates the product, adds the value
in {\em rs3}, and writes the final result to {\em rd}. FNMSUB.S
computes {\em -(rs1$\times$rs2)+rs3}.

FNMADD.S multiplies the values
in {\em rs1} and {\em rs2}, negates the product, subtracts the value
in {\em rs3}, and writes the final result to {\em rd}. FNMADD.S
computes {\em -(rs1$\times$rs2)-rs3}.

\begin{commentary}
The FNMSUB and FNMADD instructions are counterintuitively named, owing to the
naming of the corresponding instructions in MIPS-IV.  The MIPS instructions
were defined to negate the sum, rather than negating the product as the
RISC-V instructions do, so the naming scheme was more rational at the time.
The two definitions differ with respect to signed-zero results.  The RISC-V
definition matches the behavior of the x86 and ARM fused multiply-add
instructions, but unfortunately the RISC-V FNMSUB and FNMADD instruction
names are swapped compared to x86 and ARM.
\end{commentary}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{rs3} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
src3 & S & src2 & src1 & RM  & dest & F[N]MADD/F[N]MSUB  \\
\end{tabular}
\end{center}

\begin{commentary}
 The fused multiply-add (FMA) instructions consume a large part of the
 32-bit instruction encoding space.  Some alternatives considered were
 to restrict FMA to only use dynamic rounding modes, but static
 rounding modes are useful in code that exploits the lack of product
 rounding.  Another alternative would have been to use rd to provide
 rs3, but this would require additional move instructions in some
 common sequences.  The current design still leaves a large portion of
 the 32-bit encoding space open while avoiding having FMA be
 non-orthogonal.
\end{commentary}

The fused multiply-add instructions must set the invalid operation exception flag
when the multiplicands are $\infty$ and zero, even when the addend is a quiet
NaN.
\begin{commentary}
The IEEE 754-2008 standard permits, but does not require, raising the
invalid exception for the operation \mbox{$\infty\times 0\ +$ qNaN}.
\end{commentary}

\section{Single-Precision Floating-Point Conversion and Move \mbox{Instructions}}

Floating-point-to-integer and integer-to-floating-point conversion
instructions are encoded in the OP-FP major opcode space.
FCVT.W.S or FCVT.L.S converts a floating-point number
in floating-point register {\em rs1} to a signed 32-bit or 64-bit
integer, respectively, in integer register {\em rd}.  FCVT.S.W
or FCVT.S.L converts a 32-bit or 64-bit signed integer,
respectively, in integer register {\em rs1} into a floating-point
number in floating-point register {\em rd}. FCVT.WU.S,
FCVT.LU.S, FCVT.S.WU, and FCVT.S.LU variants
convert to or from unsigned integer values.
For XLEN$>32$, FCVT.W[U].S sign-extends the 32-bit result to the
destination register width.
FCVT.L[U].S and FCVT.S.L[U] are RV64-only instructions.
If the rounded result is not representable in the destination format,
it is clipped to the nearest value and the invalid flag is set.
Table~\ref{tab:int_conv} gives the range of valid inputs for FCVT.{\em int}.S
and the behavior for invalid inputs.

\begin{table}[htp]
\begin{small}
\begin{center}
\begin{tabular}{|l|r|r|r|r|}
\hline
 & FCVT.W.S & FCVT.WU.S & FCVT.L.S & FCVT.LU.S \\
\hline
Minimum valid input (after rounding) & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
Maximum valid input (after rounding) & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
\hline
Output for out-of-range negative input & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
Output for $-\infty$ & $-2^{31}$ & 0 & $-2^{63}$ & 0 \\
Output for out-of-range positive input & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
Output for $+\infty$ or NaN & $2^{31}-1$ & $2^{32}-1$ & $2^{63}-1$ & $2^{64}-1$ \\
\hline
\end{tabular}
\end{center}
\end{small}
\caption{Domains of float-to-integer conversions and behavior for invalid inputs.}
\label{tab:int_conv}
\end{table}

All floating-point to integer and integer to floating-point conversion
instructions round according to the {\em rm} field.  A floating-point register
can be initialized to floating-point positive zero using FCVT.S.W {\em rd},
{\tt x0}, which will never set any exception flags.

All floating-point conversion instructions set the Inexact exception flag if
the rounded result differs from the operand value and the Invalid exception
flag is not set.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCVT.{\em int}.{\em fmt} & S & W[U]/L[U] & src & RM  & dest & OP-FP  \\
FCVT.{\em fmt}.{\em int} & S & W[U]/L[U] & src & RM  & dest & OP-FP  \\
\end{tabular}
\end{center}

Floating-point to floating-point sign-injection instructions, FSGNJ.S,
FSGNJN.S, and FSGNJX.S, produce a result that takes all bits except
the sign bit from {\em rs1}.  For FSGNJ, the result's sign bit is {\em
  rs2}'s sign bit; for FSGNJN, the result's sign bit is the opposite
of {\em rs2}'s sign bit; and for FSGNJX, the sign bit is the XOR of
the sign bits of {\em rs1} and {\em rs2}.  Sign-injection instructions
do not set floating-point exception flags, nor do they canonicalize
NaNs.  Note, FSGNJ.S {\em rx, ry,
  ry} moves {\em ry} to {\em rx} (assembler pseudoinstruction FMV.S {\em rx,
  ry}); FSGNJN.S {\em rx, ry, ry} moves the negation of {\em ry} to
{\em rx} (assembler pseudoinstruction FNEG.S {\em rx, ry}); and FSGNJX.S {\em rx,
  ry, ry} moves the absolute value of {\em ry} to {\em rx} (assembler
pseudoinstruction FABS.S {\em rx, ry}).

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FSGNJ & S & src2 & src1 & J[N]/JX & dest & OP-FP  \\
\end{tabular}
\end{center}

\begin{commentary}
The sign-injection instructions
provide floating-point MV, ABS, and NEG,
as well as supporting a few other operations, including the IEEE copySign
operation and sign manipulation in transcendental math function
libraries.  Although MV, ABS, and NEG only need a single register
operand, whereas FSGNJ instructions need two, it is unlikely most
microarchitectures would add optimizations to benefit from the reduced
number of register reads for these relatively infrequent instructions.
Even in this case, a microarchitecture can simply detect when both
source registers are the same for FSGNJ instructions and only read a
single copy.
\end{commentary}

Instructions are provided to move bit patterns between the
floating-point and integer registers.  FMV.X.W moves the
single-precision value in floating-point register {\em rs1}
represented in IEEE 754-2008 encoding to the lower 32 bits of integer
register {\em rd}.  The bits are not
modified in the transfer, and in particular, the payloads of
non-canonical NaNs are preserved.
For RV64, the higher 32 bits of the destination
register are filled with copies of the floating-point number's sign
bit.

FMV.W.X moves the single-precision value encoded in IEEE
754-2008 standard encoding from the lower 32 bits of integer register
{\em rs1} to the floating-point register {\em rd}.  The bits are not
modified in the transfer, and in particular, the payloads of
non-canonical NaNs are preserved.

\begin{commentary}
The FMV.W.X and FMV.X.W instructions were previously called FMV.S.X
and FMV.X.S.  The use of W is more consistent with their semantics as
an instruction that moves 32 bits without interpreting them.  This
became clearer after defining NaN-boxing.  To avoid disturbing
existing code, both the W and S versions will be supported by tools.
\end{commentary}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FMV.X.W & S & 0    & src  & 000  & dest & OP-FP  \\
FMV.W.X & S & 0    & src  & 000  & dest & OP-FP  \\
\end{tabular}
\end{center}

\begin{commentary}
The base floating-point ISA was defined so as to allow implementations
to employ an internal recoding of the floating-point format in
registers to simplify handling of subnormal values and possibly to
reduce functional unit latency.  To this end, the base ISA avoids
representing integer values in the floating-point registers by
defining conversion and comparison operations that read and write the
integer register file directly.  This also removes many of the common
cases where explicit moves between integer and floating-point
registers are required, reducing instruction count and critical paths
for common mixed-format code sequences.
\end{commentary}

\section{Single-Precision Floating-Point Compare Instructions}

Floating-point compare instructions (FEQ.S, FLT.S, FLE.S) perform the
specified comparison between floating-point registers ($\mbox{\em rs1}
= \mbox{\em rs2}$, $\mbox{\em rs1} < \mbox{\em rs2}$, $\mbox{\em rs1} \leq
\mbox{\em rs2}$) writing 1 to the integer register {\em rd} if the condition
holds, and 0 otherwise.

FLT.S and FLE.S perform what the IEEE 754-2008 standard refers to as {\em
signaling} comparisons: that is, they set the invalid operation exception flag
if either input is NaN.  FEQ.S performs a {\em quiet} comparison: it only
sets the invalid operation exception flag if either input is a signaling NaN.
For all three instructions,
the result is 0 if either operand is NaN.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCMP & S & src2 & src1 & EQ/LT/LE & dest & OP-FP  \\
\end{tabular}
\end{center}

\begin{commentary}
The F extension provides a $\leq$ comparison, whereas the base ISA provides
a $\geq$ branch comparison.  Because $\leq$ can be synthesized from $\geq$ and
vice-versa, there is no performance implication to this inconsistency, but it
is nevertheless an unfortunate incongruity in the ISA.
\end{commentary}

\section{Single-Precision Floating-Point Classify Instruction}

The FCLASS.S instruction examines the value in floating-point register {\em
rs1} and writes to integer register {\em rd} a 10-bit mask that indicates
the class of the floating-point number.  The format of the mask is
described in Table~\ref{tab:fclass}.  The corresponding bit in {\em rd} will
be set if the property is true and clear otherwise.  All other bits in
{\em rd} are cleared.  Note that exactly one bit in {\em rd} will be set.
FCLASS.S does not set the floating-point exception flags.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCLASS & S & 0 & src & 001 & dest & OP-FP  \\
\end{tabular}
\end{center}

\begin{table}[htp]
\begin{small}
\begin{center}
\begin{tabular}{|c|l|}
\hline
{\em rd} bit &
Meaning \\
\hline
0 & {\em rs1} is $-\infty$. \\
1 & {\em rs1} is a negative normal number. \\
2 & {\em rs1} is a negative subnormal number. \\
3 & {\em rs1} is $-0$. \\
4 & {\em rs1} is $+0$. \\
5 & {\em rs1} is a positive subnormal number. \\
6 & {\em rs1} is a positive normal number. \\
7 & {\em rs1} is $+\infty$. \\
8 & {\em rs1} is a signaling NaN. \\
9 & {\em rs1} is a quiet NaN. \\
\hline
\end{tabular}
\end{center}
\end{small}
\caption{Format of result of FCLASS instruction.}
\label{tab:fclass}
\end{table}


\subsection{Optimization for the low density
scenario}\label{subsec:ldoptimization}

Also in this case, we have run a full factorial analysis, with low values of
each parameter, in order to identify the minimum values required to reach the
coverage. Each possible configuration (\(750\)) has been run with 10
repetitions. The complete analysis can be found in \code{coverage.ipynb}. The
configuration used is named ``LowDensityCoverage''. We have found out that to
reach at least the \(99\%\) of the coverage, we need to have a broadcast radius
of at least \(23m\), but we also need higher values for \(m\) and \(D\). If we
use \(R\!=\!25m\) we get better results for the other parameters. In particular,
we have found the following minimum configuration the we consider ``good'' and
``well balanced'' since it does not use the value \code{1} for any of the
parameters.

\begin{center}
	\begin{tabular}{cccc}
		\toprule
		R & T & m & \(\max(\delta)\) \\
		\midrule
		\(25m\) & \(2s\) & \(2\,\mathit{copies}\) & \(2s\) \\
		\bottomrule
	\end{tabular}
\end{center}

As in the high density scenario, to optimize the \standout{total broadcast time}
we need to increase the broadcast radius or decrease the size of the hear
window. The results are in the file \code{broadcast-time.ipynb}. The
configuration used is named ``LowDensityTime'', where we use, as suggested from
the plots of \code{2kr.ipynb}, high values for \(m\) and low value for the
maximum relay delay. As shown in \figref{fig:ldtimeff}, we see that with low
values of T we can reduce a lot the broadcast time (as expected). If we do not
want to sacrifice the energy efficiency, it is convenient to only reduce the
hear window, without increasing the radius (also increase a just a little \(R\)
is not convenient because there isn't a big difference in the time).

\begin{figure}[hbt]
	\centering
	\includegraphics[width=0.6\textwidth]{img/ld/broadcasttime-R-ffplot}
	\caption{The broadcast time is lower with higher values of the broadcast
	radius and lower values of the size of the hear
	window (95\% confidence intervals)}\label{fig:ldtimeff}
\end{figure}

To optimize the \standout{energy efficiency}, we have to study the number of
messages. The analysis can be found in \code{messages.ipynb}. We use low values
for the broadcast radius (that obviously improves energy efficiency). Other
factors taken into considerations are the one we have identified as relevant in
\secref{subsec:ld2kr}, namely the maximum number of copies and the size of the
hear window. The configuration used is named ``LowDensityMessages''.

As we can see from \figref{fig:ldmessagesff}, we get that the maximum number of
copies hugely affects the total number of messages sent, as previously found by
the \(2^{k}r\) analysis. Also increasing the size of the hear window have
benefits (but lower benefits, as found by the \(2^{k}r\)).

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.7\textwidth]{img/ld/messages-R-ffplot.png}
	\caption{With low values of the maximum number of copies and higher
	values for the size of the hear window, we get a lower number of
	messages sent}\label{fig:ldmessagesff}
\end{figure}

So, in order to improve the energy efficiency, since we can not increase the
broadcast radius, we need to use surely low values for \(m\) and also an higher
\(T\). Increasing \(T\) also increases the broadcast time, so a trade-off
decision is needed in this parameter. Because manipulating the hear window we
have only little benefits in the energy consumption, we can decide to use a low
or medium value, which implies a little bit more of consumption but a large
benefit in the broadcast time.

Regarding the \standout{total number of collisions}, we can reduce it by
reducing the broadcast radius and the maximum number of copies. Also helps
increasing the maximum relay delay, such as in the high density scenario.
Factorial analysis with the \(m\) and \(\max(\delta)\) parameters is available
in \code{collisions.ipynb}, using the configuration named
``LowDensityCollisions''. \figref{fig:ldcollisionsff} shows the results:
increasing \(\max(\delta)\) should allow to have even a lower number of
collisions. \(m\!=\!2\) is a good setup for this parameter since it allows to
completely exploit the advantages of the \emph{trickle relaying} algorithm in
order to reduce the number of collisions and the number of messages sent.

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.5\textwidth]{img/ld/collisions-D-ffplot}
	\caption{The number of collisions is linearly dependent on the maximum
	relay delay. Also, trickle relaying can be exploited with low values of
	\(m\) in order to reduce the number of
	collisions}\label{fig:ldcollisionsff}
\end{figure}

\subsubsection{Conclusions}\label{subsubsec:ldconclusions}

\begin{itemize}
	\item The minimal configuration to get a nearly perfect coverage is with
		\(R\!=\!25m\), \(T\!=\!2s\), \(m\!=\!2\) and
		\(\max(\delta)\!=\!2s\). Higher values for these parameters does
		not break the coverage.
	\item If a low total broadcast time is a main objective, increasing
		\(R\) is effective, but is better to reduce \(T\).
	\item If instead a better energy efficiency is the main objective, \(R\)
		can not be increased and \(T\) should not be reduced. A
		trade-off decision between a low broadcast time and a good
		energy efficiency is needed. We have to consider that for this
		configuration changing \(T\) has a greater influence for the
		broadcast time than the one related to the number of messages.
	\item Also in this configuration \(m\!=\!2\) is perfect to have a lower
		number of collisions and a better energy efficiency without
		sacrificing the broadcast time, thanks to trickle relaying.
	\item \(\max(\delta)\) should be high, in order to reduce the total
		number of collisions, but not too much, in order to avoid an
		increase in the broadcast time due to users waiting time.
\end{itemize}


\subsection{The Mankiw-Romer-Weil model}

We add human capital to the Solow-Swan model.


\chapter{Classical and Modern Spectrum Estimation}

\input{sections/part1/11.tex}
\input{sections/part1/12.tex}
\input{sections/part1/13.tex}
\input{sections/part1/14.tex}
\input{sections/part1/15.tex}
\input{sections/part1/16.tex}


\chapter{Introduction}\label{cha:intro}
This chapter gives the reader an introduction to voxels, its uses and ways to create voxels from a model.
It also serves the purpose of motivating the thesis, as well as describing the problem it is out to solve.
Finally, it defines the delimitations of the thesis and presents the company, at which this thesis was conducted at.

\section{Background}
In computer graphics, a 3D model is built up of triangles which describes the surface of the model.
This means it does not store any information to represent the inside of the model.
In order to represent the inside, a volumetric data structure is needed.
Usually, this is done by storing \textit{voxels} in a uniform 3D grid.
A voxel can be described as data at a position in a grid.
This can be any form of data, such as occupancy, color, material or density.

% \textit{Voxel} is a word that has a lot of meaning in computer graphics.
% The simplest form of a voxel is a cube in a 3D-environment, but other representations of voxel data also exist.
% One such representation is marching cubes~\cite{marching-cubes}, where voxels are defined as density functions to a surface.
% This can create smooth surfaces from volume data, which has its uses in medical imaging~\cite{marching-cubes} and 3D-terrain~\cite{marching-cubes-terrain}.

As voxels are just a way to represent volumetric data, they have been used in a wide range of applications, such as global illumination~\cite{crassin-VCT}, medical imaging~\cite{marching-cubes,voxel-medicin} and collision culling~\cite{voxel-collision}.
These applications either store a voxel representation of models (especially true for medical imaging) or need to convert models into voxels.
This process is called \textit{voxelization} and has been widely studied in the past.
Some methods for voxelizations include triangle-box intersection~\cite{SAT-voxelization}, rasterization~\cite{octree-voxelization} and depth buffer~\cite{depth-buffer}.

Recently, a study was published by \call{scanline-voxelization} proposing a new method to voxelize a model.
The basics of the method is to voxelize the model by performing line voxelization at different stages.
This method is the basis of this thesis and will further be called the \textit{optimal scanline}.
% The authors used both real and integer line voxelization based on~\call{voxeltraversal}.
% These two will further be called \textit{Real Line Voxelization} (RLV) and \textit{Integer Line Voxelization} (ILV).
% They mentioned ILV was slightly more efficient ($\sim$3\%), but the actual data was not published.

\newpage

\section{Aim}
This thesis aims to do an investigation of how the line voxelization algorithm affects the performance of the optimal scanline.
This includes both floating-point and integer line voxelizations.

The thesis also investigates the approximation error caused by using the integer versions of the algorithm.
This was done in \cite{scanline-voxelization}, but the authors only compared the voxel count.
Which means if a voxel is moved somewhere else, it would not produce any error.
As such, this thesis aims to measure this error in another metric, which can describe those errors.

\section{Research Questions}
With the aim of the thesis defined, two research questions are formed as a baseline of the thesis.
These are presented below:
\begin{enumerate}
  \item \label{que:linealg} Which line voxelization algorithm performs best for the optimal scanline?
  \item \label{que:erroraprox} How great is the approximation error of the integer versions of the optimal scanline?
  % \item \label{que:combine} Can the different line voxelization be combined to improve performance and accuracy?
\end{enumerate}
A better performance in this case is defined as how fast the execution of the voxelization is.
It is not a metric of the error or the memory usage of the algorithms.

\section{Delimitations}
The implementation of the thesis ran on \textit{Amazon Web Services} (AWS), on a computer running Ubuntu 18.04 with an NVIDIA Tesla T4 graphics card with driver version 440.59.

The rendering of the voxelization was done using OpenGL.
As the focus was not on supporting older devices, the OpenGL version 4.6 was used.

The computing language of choice was CUDA, as such, other languages were not considered for the implementation.
Again, as there is no need to support older devices, CUDA 10.2 was used.

The line algorithms that were evaluated were limited to a voxel traversal algorithm by \call{voxeltraversal}, its integer version and Bresenham.
As Bresenham is predominantly a 2D line drawing algorithm, it was extended to 3D using a method proposed by \call{3d-bresenham}.

The evaluations were also limited to three different models and voxel grid resolutions between 128-2048.

\newpage

\section{Mindroad}
This master thesis was conducted on behalf of MindRoad.
MindRoad is a software company which specializes in embedded systems, web development and mobile applications.
They also provide courses in software development, such as C++, Python, GPU-programming, Linux and driver development.


In this chapter we will combine the specifications languages \oz{} and \picalc{} into the combination $\pi$-OZ, and we will study its transformational semantics.
\section{Syntax}
\label{sec_comp_oz_pi_syntax}
\input{chapters/mainpart/the_compination_pi_oz/sections/syntax/syntax}

\section{Transformational semantics}
\label{sec_comp_oz_pi_transformational_semantics}
\input{chapters/mainpart/the_compination_pi_oz/sections/transformational_semantics/transformational_semantics}


\chapter{Multiply-Accumulate}
\label{chap:mac}

\rvcore uses a single-cycle 32-bit $\times$ 32-bit multiplier with a 32-bit
result. Only a subset of the standard M extension is implemented, i.e. the
\instr{mul} instruction. Divisions and multiplications that return the upper
32-bit of the result are not supported.

Specifically the following instruction is supported:
\begin{itemize}
  \item \instr{mul}
\end{itemize}

The following instructions are \textbf{not} supported:
\begin{itemize}
  \item \instr{mulh}
  \item \instr{mulhs}
  \item \instr{mulhu}
  \item \instr{div}
  \item \instr{divu}
  \item \instr{rem}
  \item \instr{remu}
\end{itemize}

Instead \rvcore supports non-standard extensions for multiply-accumulate and
half-word multiplications.

\section{Instructions}

\subsection{p.mul rD, rs1, rs2}
Multiply on 32-bit $\times$ 32-bit with a 32-bit result.

\begin{center}
  \begin{bytefield}[endianness=big,bitwidth=1.3em]{32}
    \bitheader{31,30,29,25,24,20,19,15,14,12,11,7,6,0} \\
    \bitbox{7}{ funct7                            }
    \bitbox{5}{ rs2                               }
    \bitbox{5}{ rs1                               }
    \bitbox{3}{ funct3                            }
    \bitbox{5}{ rd                                }
    \bitbox{7}{ opcode                            } \\

    \bitbox[]{7}{ 000 0001 }
    \bitbox[]{5}{ src2 }
    \bitbox[]{5}{ src1 }
    \bitbox[]{3}{ 000 }
    \bitbox[]{5}{ dest }
    \bitbox[]{7}{ 011 0011 }
  \end{bytefield}
\end{center}
\textbf{Operation:} \texttt{rD = rs1 * rs2}

\subsection{p.mac rD, rs1, rs2}
Multiply-Accumulate on 32-bit $\times$ 32-bit with a 32-bit result.

\begin{center}
  \begin{bytefield}[endianness=big,bitwidth=1.3em]{32}
    \bitheader{31,30,29,25,24,20,19,15,14,12,11,7,6,0} \\
    \bitbox{7}{ funct7                            }
    \bitbox{5}{ rs2                               }
    \bitbox{5}{ rs1                               }
    \bitbox{3}{ funct3                            }
    \bitbox{5}{ rd                                }
    \bitbox{7}{ opcode                            } \\

    \bitbox[]{7}{ 000 0001 }
    \bitbox[]{5}{ src2 }
    \bitbox[]{5}{ src1 }
    \bitbox[]{3}{ 001 }
    \bitbox[]{5}{ dest }
    \bitbox[]{7}{ 011 0011 }
  \end{bytefield}
\end{center}
\textbf{Operation:} \texttt{rD += rs1 * rs2}

\subsection{p.mul\{s,hhs,u,hhu\} rD, rs1, rs2}
Multiply-Accumulate on 16-bit $\times$ 16-bit with a 32-bit result. The
half-word and sign-mode that is used for the multiplication can be selected.

\begin{center}
  \begin{bytefield}[endianness=big,bitwidth=1.3em]{32}
    \bitheader{31,30,29,25,24,20,19,15,14,13,12,11,7,6,0} \\
    \bitbox{1}{ S                                 }
    \bitbox{1}{ P                                 }
    \bitbox{5}{ imm5                              }
    \bitbox{5}{ rs2                               }
    \bitbox{5}{ rs1                               }
    \bitbox{1}{ R                                 }
    \bitbox{2}{ subop                             }
    \bitbox{5}{ rd                                }
    \bitbox{7}{ opcode                            } \\

    \bitbox[]{1}{ S     }
    \bitbox[]{1}{ P     }
    \bitbox[]{5}{ 00000 }
    \bitbox[]{5}{ src2 }
    \bitbox[]{5}{ src1 }
    \bitbox[]{1}{ 0 }
    \bitbox[]{2}{ 00 }
    \bitbox[]{5}{ dest }
    \bitbox[]{7}{ 101 1011 }
  \end{bytefield}
\end{center}
\textbf{Operation:} \texttt{rD = rs1[P*16+15:P*16] * rs2[P*16+15:P*16]}

S determines the zero/sign-extension of rs1 and rs2. A value of \texttt{1} means
sign-extension.

\subsection{p.mac\{s,hhs,u,hhu\} rD, rs1, rs2}
Multiply-Accumulate on 16-bit $\times$ 16-bit with a 32-bit result. The
half-word and sign-mode that is used for the multiplication can be selected.

\begin{center}
  \begin{bytefield}[endianness=big,bitwidth=1.3em]{32}
    \bitheader{31,30,29,25,24,20,19,15,14,13,12,11,7,6,0} \\
    \bitbox{1}{ S                                 }
    \bitbox{1}{ P                                 }
    \bitbox{5}{ imm5                              }
    \bitbox{5}{ rs2                               }
    \bitbox{5}{ rs1                               }
    \bitbox{1}{ R                                 }
    \bitbox{2}{ subop                             }
    \bitbox{5}{ rd                                }
    \bitbox{7}{ opcode                            } \\

    \bitbox[]{1}{ S     }
    \bitbox[]{1}{ P     }
    \bitbox[]{5}{ 00000 }
    \bitbox[]{5}{ src2 }
    \bitbox[]{5}{ src1 }
    \bitbox[]{1}{ 0 }
    \bitbox[]{2}{ 01 }
    \bitbox[]{5}{ dest }
    \bitbox[]{7}{ 101 1011 }
  \end{bytefield}
\end{center}
\textbf{Operation:} \texttt{rD += rs1[P*16+15:P*16] * rs2[P*16+15:P*16]}

S determines the zero/sign-extension of rs1 and rs2. A value of \texttt{1} means
sign-extension.