[[!tag standards]] Note on considered alternative naming schemes: we decided to switch to using the reduced mnemonic naming scheme (over some people's objections) since it would be 5 instructions instead of dozens, though we did consider trying to match PowerISA's existing naming scheme for the instructions rather than only for the instruction aliases. # FPR-to-GPR and GPR-to-FPR TODO special constants instruction (e, tau/N, ln 2, sqrt 2, etc.) -- exclude any constants available through fmvis **Draft Status** under development, for submission as an RFC Links: * * * * * fmvis * int-fp RFC * [[int_fp_mv/appendix]] * [[sv/rfc/ls002]] - `fmvis` and `fishmv` External RFC Formal Submission * [[sv/rfc/ls006]] - int-fp-mv External RFC Formal Submission 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: * Int -> Float * **standard IEEE754** - used by most languages and CPUs * Float -> Int * **standard OpenPOWER** - saturation with NaN converted to minimum valid integer * **Java/Saturating** - saturation with NaN converted to 0 * **JavaScript** - modulo wrapping with Inf/NaN converted to 0 The assembly listings in the [[int_fp_mv/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 [[int_fp_mv/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. These instructions **always** save resources compared to FP-load for exactly the same reason that `li` saves resources: an L1-Data-Cache and memory read is avoided. *IBM may consider it worthwhile to extend these two instructions to v3.1 Prefixed (`pfmvis` and `pfishmv`: 8RR, imm0 extended). If so it is recommended that `pfmvis` load a full FP32 immediate and `pfishmv` supplies the three high missing exponent bits (numbered 8 to 10) and the lower additional 29 mantissa bits (23 to 51) needed to construct a full FP64 immediate. Strictly speaking the sequence `fmvis fishmv pfishmv` achieves the same effect in the same number of bytes as `pfmvis pfishmv`, making `pfmvis` redundant.* Just as Floating-point Load does not set FP Flags neither does fmvis or fishmv. As fishmv is specifically intended to work in conjunction with fmvis to provide additional accuracy, all bits other than those which would have been set by a prior fmvis instruction are deliberately ignored. (If these instructions involved reading from registers rather than immediates it would be a different story). ## 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](#GPR-to-FPR-conversions) to instead write `+0.0` if `RA` is register `0`, at least allowing clearing FPRs. `fmvis` fits with DX-Form: | 0-5 | 6-10 | 11-15 | 16-25 | 26-30 | 31 | Form | |--------|------|-------|-------|-------|-----|---------| | Major | FRS | d1 | d0 | XO | d2 | DX-Form | Pseudocode: bf16 = d0 || d1 || d2 # create BF16 immediate fp32 = bf16 || [0]*16 # convert BF16 to FP32 FRS = DOUBLE(fp32) # convert FP32 to FP64 Special registers altered: None ## Float Immediate Second-Half MV `fishmv FRS, D` DX-Form: | 0-5 | 6-10 | 11-15 | 16-25 | 26-30 | 31 | Form | |--------|------|-------|-------|-------|-----|---------| | Major | FRS | d1 | d0 | XO | d2 | 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 (stored as usual in FP64 Format within the FPR). 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` immediate to FP64 (Double) format. This is taken into consideration as can be seen in the pseudocode below. Pseudocode: fp32 <- SINGLE((FRS)) # convert to FP32 fp32[16:31] <- d0 || d1 || d2 # replace LSB half FRS <- DOUBLE(fp32) # convert back to FP64 Special registers altered: None **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 ``` [[!inline pages="openpower/sv/int_fp_mv/moves_and_conversions" raw=yes ]]