FPR-to-GPR and GPR-to-FPR

Draft Status under development, for submission as an RFC

Links:

• https://bugs.libre-soc.org/show_bug.cgi?id=650
• https://bugs.libre-soc.org/show_bug.cgi?id=230#c71
• https://bugs.libre-soc.org/show_bug.cgi?id=230#c74
• https://bugs.libre-soc.org/show_bug.cgi?id=230#c76
• appendix

Trademarks:

• Rust is a Trademark of the Rust Foundation
• Java and Javascript are Trademarks of Oracle
• LLVM is a Trademark of the LLVM Foundation
• SPIR-V is a Trademark of the Khronos Group
• OpenCL is a Trademark of Apple, Inc.

Referring to these Trademarks within this document is by necessity, in order to put the semantics of each language into context, and is considered "fair use" under Trademark Law.

Introduction:

High-performance CPU/GPU software needs to often convert between integers and floating-point, therefore fast conversion/data-movement instructions are needed. Also given that initialisation of floats tends to take up considerable space (even to just load 0.0) the inclusion of two compact format float immediate instructions is up for consideration using 16-bit immediates. BF16 is one of the formats: a second instruction allows a full accuracy FP32 to be constructed.

Libre-SOC will be compliant with the Scalar Floating-Point Subset (SFFS) i.e. is not implementing VMX/VSX, and with its focus on modern 3D GPU hybrid workloads represents an important new potential use-case for OpenPOWER.

Prior to the formation of the Compliancy Levels first introduced in v3.0C and v3.1 the progressive historic development of the Scalar parts of the Power ISA assumed that VSX would always be there to complement it. However With VMX/VSX not available in the newly-introduced SFFS Compliancy Level, the existing non-VSX conversion/data-movement instructions require a Vector of load/store instructions (slow and expensive) to transfer data between the FPRs and the GPRs. For a modern 3D GPU this kills any possibility of a competitive edge. Also, because SimpleV needs efficient scalar instructions in order to generate efficient vector instructions, adding new instructions for data-transfer/conversion between FPRs and GPRs multiplies the savings.

In addition, the vast majority of GPR <-> FPR data-transfers are as part of a FP <-> Integer conversion sequence, therefore reducing the number of instructions required is a priority.

Therefore, we are proposing adding:

• FPR load-immediate instructions, one equivalent to BF16, the other increasing accuracy to FP32
• FPR <-> GPR data-transfer instructions that just copy bits without conversion
• FPR <-> GPR combined data-transfer/conversion instructions that do Integer <-> FP conversions

If adding new Integer <-> FP conversion instructions, the opportunity may be taken to modernise the instructions and make them well-suited for common/important conversion sequences:

• standard IEEE754 - used by most languages and CPUs
• standard OpenPOWER - saturation with NaN converted to minimum valid integer
• Java - saturation with NaN converted to 0
• JavaScript - modulo wrapping with Inf/NaN converted to 0

The assembly listings in the appendix show how costly some of these language-specific conversions are: Javascript, the worst case, is 32 scalar instructions including seven branch instructions.

Proposed New Scalar Instructions

All of the following instructions use the standard OpenPower conversion to/from 64-bit float format when reading/writing a 32-bit float from/to a FPR. All integers however are sourced/stored in the GPR.

Integer operands and results being in the GPR is the key differentiator between the proposed instructions (the entire rationale) compared to existing Scalar Power ISA. In all existing Power ISA Scalar conversion instructions, all operands are FPRs, even if the format of the source or destination data is actually a scalar integer.

(The existing Scalar instructions being FP-FP only is based on an assumption that VSX will be implemented, and VSX is not part of the SFFS Compliancy Level. An earlier version of the Power ISA used to have similar FPR<->GPR instructions to these: they were deprecated due to this incorrect assumption that VSX would always be present).

Note that source and destination widths can be overridden by SimpleV SVP64, and that SVP64 also has Saturation Modes in addition to those independently described here. SVP64 Overrides and Saturation work on both Fixed and Floating Point operands and results. The interactions with SVP64 are explained in the appendix

Float load immediate

These are like a variant of fmvfg and oris, combined. Power ISA currently requires a large number of instructions to get Floating Point constants into registers. fmvis on its own is equivalent to BF16 to FP32/64 conversion, but if followed up by fishmv an additional 16 bits of accuracy in the mantissa may be achieved.

IBM may consider it worthwhile to extend these two instructions to v3.1 Prefixed (pfmvis and pfishmv). If so it is recommended that pfmvis load a full FP32 immediate and pfishmv extend the lower 32-bits to construct a full FP64 immediate.

Load BF16 Immediate

fmvis FRS, D

Reinterprets D << 16 as a 32-bit float, which is then converted to a 64-bit float and written to FRS. This is equivalent to reinterpreting D as a BF16 and converting to 64-bit float. There is no need for an Rc=1 variant because this is an immediate loading instruction.

Example:

# clearing a FPR
fmvis f4, 0 # writes +0.0 to f4
# loading handy constants
fmvis f4, 0x8000 # writes -0.0 to f4
fmvis f4, 0x3F80 # writes +1.0 to f4
fmvis f4, 0xBF80 # writes -1.0 to f4
fmvis f4, 0xBFC0 # writes -1.5 to f4
fmvis f4, 0x7FC0 # writes +qNaN to f4
fmvis f4, 0x7F80 # writes +Infinity to f4
fmvis f4, 0xFF80 # writes -Infinity to f4
fmvis f4, 0x3FFF # writes +1.9921875 to f4

# clearing 128 FPRs with 2 SVP64 instructions
# by issuing 32 vec4 (subvector length 4) ops
setvli VL=MVL=32
sv.fmvis/vec4 f0, 0 # writes +0.0 to f0-f127

Important: If the float load immediate instruction(s) are left out, change all GPR to FPR conversion instructions to instead write +0.0 if RA is register 0, at least allowing clearing FPRs.

fmvis fits with DX-Form:

Pseudocode:

bf16 = d0 || d1 || d2
fp32 = bf16 || [0]*16
FRS = Single_to_Double(fp32)

Float Immediate, Second Half

fishmv FRS, D

DX-Form:

Strategically similar to how oris is used to construct 32-bit Integers, an additional 16-bits of immediate is inserted into FRS to extend its accuracy to a full FP32. If a prior fmvis instruction had been used to set the upper 16-bits of an FP32 value, fishmv contains the lower 16-bits.

The key difference between using li and oris to construct 32-bit GPR Immediates and fishmv is that the fmvis will have converted the BF16 to FP64 (Double) format. This is taken into consideration as can be seen in the pseudocode below

Pseudocode:

fp32 = Double_to_Single(FRS)
n = fp32[0:15] || d0 || d1 || d2
FRS = Single_to_Double(n)

This instruction performs a Read-Modify-Write. FRS is read, the additional 16 bit immediate inserted, and the result also written to FRS

Example:

# these two combined instructions write 0x3f808000
# into f4 as an FP32 to be converted to an FP64.
# actual contents in f4 after conversion: 0x3ff0_1000_0000_0000
# first the upper bits, happens to be +1.0
fmvis f4, 0x3F80 # writes +1.0 to f4
# now write the lower 16 bits of an FP32
fishmv f4, 0x8000 # writes +1.00390625 to f4

Moves

These instructions perform a straight unaltered bit-level copy from one Register File to another.

FPR to GPR moves

• fmvtg RT, FRA
• fmvtg. RT, FRA

move a 64-bit float from a FPR to a GPR, just copying bits directly. As a direct bitcopy, no exceptions occur and no status flags are set.

Rc=1 tests RT and sets CR0, exactly like all other Scalar Fixed-Point operations.

• fmvtgs RT, FRA
• fmvtgs. RT, FRA

move a 32-bit float from a FPR to a GPR, just copying bits. Converts the 64-bit float in FRA to a 32-bit float, then writes the 32-bit float to RT. Effectively, fmvtgs is a macro-fusion of frsp fmvtg and therefore has the exact same exception and flags behaviour of frsp

Unlike frsp however, with RT being a GPR, Rc=1 follows standard integer behaviour, i.e. tests RT and sets CR0.

GPR to FPR moves

fmvfg FRT, RA

move a 64-bit float from a GPR to a FPR, just copying bits. No exceptions are raised, no flags are altered of any kind.

Rc=1 tests FRT and sets CR1

fmvfgs FRT, RA

move a 32-bit float from a GPR to a FPR, just copying bits. Converts the 32-bit float in RA to a 64-bit float, then writes the 64-bit float to FRT. Effectively, fmvfgs is a macro-fusion of fmvfg frsp and therefore has the exact same exception and flags behaviour of frsp

Rc=1 tests FRT and sets CR1

TODO: clear statement on evaluation as to whether exceptions or flags raised as part of the FP conversion (not the int bitcopy part, the conversion part. the semantics should really be the same as frsp)

v3.0C section 4.6.7.1 states:

FPRF is set to the class and sign of the result, except for Invalid Operation Exceptions when VE=1.

Special Registers Altered:
  FPRF FR FI
  FX OX UX XX VXSNAN
  CR1 (if Rc=1)

Conversions

Unlike the move instructions these instructions perform conversions between Integer and Floating Point. Truncation can therefore occur, as well as exceptions.

Mode values:

GPR to FPR conversions

Format

All of the following GPR to FPR conversions use the rounding mode from FPSCR.

• fcvtfgw FRT, RA Convert from 32-bit signed integer in the GPR RA to 64-bit float in FRT.
• fcvtfgws FRT, RA Convert from 32-bit signed integer in the GPR RA to 32-bit float in FRT.
• fcvtfguw FRT, RA Convert from 32-bit unsigned integer in the GPR RA to 64-bit float in FRT.
• fcvtfguws FRT, RA Convert from 32-bit unsigned integer in the GPR RA to 32-bit float in FRT.
• fcvtfgd FRT, RA Convert from 64-bit signed integer in the GPR RA to 64-bit float in FRT.
• fcvtfgds FRT, RA Convert from 64-bit signed integer in the GPR RA to 32-bit float in FRT.
• fcvtfgud FRT, RA Convert from 64-bit unsigned integer in the GPR RA to 64-bit float in FRT.
• fcvtfguds FRT, RA Convert from 64-bit unsigned integer in the GPR RA to 32-bit float in FRT.

FPR to GPR (Integer) conversions

Different programming languages turn out to have completely different semantics for FP to Integer conversion. Below is an overview of the different variants, listing the languages and hardware that implements each variant.

Standard IEEE754 conversion

This conversion is outlined in the IEEE754 specification. It is used by nearly all programming languages and CPUs. In the case of OpenPOWER, the rounding mode is read from FPSCR

Standard OpenPower conversion

This conversion, instead of exact IEEE754 Compliance, performs "saturation with NaN converted to minimum valid integer". This is also exactly the same as the x86 ISA conversion semantics. OpenPOWER however has instructions for both:

• rounding mode read from FPSCR
• rounding mode always set to truncate

Java conversion

For the sake of simplicity, the FP -> Integer conversion semantics generalized from those used by Java's semantics (and Rust's as operator) will be referred to as Java conversion semantics.

Those same semantics are used in some way by all of the following languages (not necessarily for the default conversion method):

• Java's FP -> Integer conversion
• Rust's FP -> Integer conversion using the as operator
• LLVM's llvm.fptosi.sat and llvm.fptoui.sat intrinsics
• SPIR-V's OpenCL dialect's OpConvertFToU and OpConvertFToS instructions when decorated with the SaturatedConversion decorator.
• WebAssembly has also introduced trunc_sat_u and trunc_sat_s

JavaScript conversion

For the sake of simplicity, the FP -> Integer conversion semantics generalized from those used by JavaScripts's ToInt32 abstract operation will be referred to as JavaScript conversion semantics.

This instruction is present in ARM assembler as FJCVTZS https://developer.arm.com/documentation/dui0801/g/hko1477562192868

Format

Rc=1 and OE=1

All of these insructions have an Rc=1 mode which sets CR0 in the normal way for any instructions producing a GPR result. Additionally, when OE=1, if the numerical value of the FP number is not 100% accurately preserved (due to truncation or saturation and including when the FP number was NaN) then this is considered to be an integer Overflow condition, and CR0.SO, XER.SO and XER.OV are all set as normal for any GPR instructions that overflow.

Instructions

• fcvttgw RT, FRA, Mode Convert from 64-bit float to 32-bit signed integer, writing the result to the GPR RT. Converts using mode Mode
• fcvttguw RT, FRA, Mode Convert from 64-bit float to 32-bit unsigned integer, writing the result to the GPR RT. Converts using mode Mode
• fcvttgd RT, FRA, Mode Convert from 64-bit float to 64-bit signed integer, writing the result to the GPR RT. Converts using mode Mode
• fcvttgud RT, FRA, Mode Convert from 64-bit float to 64-bit unsigned integer, writing the result to the GPR RT. Converts using mode Mode
• fcvtstgw RT, FRA, Mode Convert from 32-bit float to 32-bit signed integer, writing the result to the GPR RT. Converts using mode Mode
• fcvtstguw RT, FRA, Mode Convert from 32-bit float to 32-bit unsigned integer, writing the result to the GPR RT. Converts using mode Mode
• fcvtstgd RT, FRA, Mode Convert from 32-bit float to 64-bit signed integer, writing the result to the GPR RT. Converts using mode Mode
• fcvtstgud RT, FRA, Mode Convert from 32-bit float to 64-bit unsigned integer, writing the result to the GPR RT. Converts using mode Mode

FP to Integer Conversion Pseudo-code

Key for pseudo-code:

OpenPower conversion semantics (section A.2 page 999 (page 1023) of OpenPower ISA v3.1):

def fp_to_int_open_power<fp, int>(v: fp) -> int:
    if v is NaN:
        return int::MIN_VALUE
    if v >= int::MAX_VALUE:
        return int::MAX_VALUE
    if v <= int::MIN_VALUE:
        return int::MIN_VALUE
    return (int)rint(v, rounding_mode)

Java conversion semantics / Rust semantics (with adjustment to add non-truncate rounding modes):

def fp_to_int_java<fp, int>(v: fp) -> int:
    if v is NaN:
        return 0
    if v >= int::MAX_VALUE:
        return int::MAX_VALUE
    if v <= int::MIN_VALUE:
        return int::MIN_VALUE
    return (int)rint(v, rounding_mode)

Section 7.1 of the ECMAScript / JavaScript conversion semantics (with adjustment to add non-truncate rounding modes):

def fp_to_int_java_script<fp, int>(v: fp) -> int:
    if v is NaN or infinite:
        return 0
    v = rint(v, rounding_mode)  # assume no loss of precision in result
    v = v mod int::VALUE_COUNT  # 2^32 for i32, 2^64 for i64, result is non-negative
    bits = (uint)v
    return (int)bits