From 2cfcda7def87b0e63b00dc43d840393e778f72ea Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Tue, 14 Mar 2023 10:25:22 +0000 Subject: [PATCH] removing this page as is should never have had time wasted on it without first discussing if the concept has alternatives or could cause harm to the Power ISA --- .../sv/int_fp_mv_replace_fmv_with_fgrev.mdwn | 509 ------------------ 1 file changed, 509 deletions(-) delete mode 100644 openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn diff --git a/openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn b/openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn deleted file mode 100644 index 0851eb0ac..000000000 --- a/openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn +++ /dev/null @@ -1,509 +0,0 @@ -[[!tag standards]] - -# 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: - -* **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 [[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 -``` - -# 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, using the same method as `stfs`, -then writes the 32-bit float to `RT`, setting the high 32-bits to zeros. -Effectively, `fmvtgs` is a macro-fusion of `stfs` and `lwz` and therefore -does not behave like `frsp` and does not set any fp exception flags. - -Since RT is 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, using the same method as `lfs`, -then writes the 64-bit float to `FRT`. Effectively, `fmvfgs` is a -macro-fusion of `stw` and `lfs` and therefore no fp exception flags are set. - -Rc=1 tests FRT and sets CR1, following usual fp Rc=1 semantics. - -# Conversions - -Unlike the move instructions -these instructions perform conversions between Integer and -Floating Point. Truncation can therefore occur, as well -as exceptions. - -Mode values: - -| Mode | `rounding_mode` | Semantics | -|------|-----------------|----------------------------------| -| 000 | from `FPSCR` | [OpenPower semantics] | -| 001 | Truncate | [OpenPower semantics] | -| 010 | from `FPSCR` | [Java semantics] | -| 011 | Truncate | [Java semantics] | -| 100 | from `FPSCR` | [JavaScript semantics] | -| 101 | Truncate | [JavaScript semantics] | -| rest | -- | illegal instruction trap for now | - -[OpenPower semantics]: #fp-to-int-openpower-conversion-semantics -[Java semantics]: #fp-to-int-java-conversion-semantics -[JavaScript semantics]: #fp-to-int-javascript-conversion-semantics - -## GPR to FPR conversions - -**Format** - -| 0-5 | 6-10 | 11-15 | 16-25 | 26-30 | 31 | Form | -|--------|------|--------|-------|-------|----|------| -| Major | FRT | //Mode | RA | XO | Rc |X-Form| - -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](#fp-to-int-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](https://docs.oracle.com/javase/specs/jls/se16/html/jls-5.html#jls-5.1.3) -* Rust's FP -> Integer conversion using the - [`as` operator](https://doc.rust-lang.org/reference/expressions/operator-expr.html#semantics) -* LLVM's - [`llvm.fptosi.sat`](https://llvm.org/docs/LangRef.html#llvm-fptosi-sat-intrinsic) and - [`llvm.fptoui.sat`](https://llvm.org/docs/LangRef.html#llvm-fptoui-sat-intrinsic) intrinsics -* SPIR-V's OpenCL dialect's - [`OpConvertFToU`](https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpConvertFToU) and - [`OpConvertFToS`](https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpConvertFToS) - instructions when decorated with - [the `SaturatedConversion` decorator](https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_decoration_a_decoration). -* WebAssembly has also introduced - [trunc_sat_u](ttps://webassembly.github.io/spec/core/exec/numerics.html#op-trunc-sat-u) and - [trunc_sat_s](https://webassembly.github.io/spec/core/exec/numerics.html#op-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](#fp-to-int-javascript-conversion-semantics). - -This instruction is present in ARM assembler as FJCVTZS - - -**Format** - -| 0-5 | 6-10 | 11-15 | 16-25 | 26-30 | 31 | Form | -|--------|------|--------|-------|-------|----|------| -| Major | RT | //Mode | FRA | XO | Rc |X-Form| - -**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`]. Similar to `fctiw` or `fctiwz` -* `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`]. Similar to `fctiwu` or `fctiwuz` -* `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`]. Similar to `fctid` or `fctidz` -* `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`]. Similar to `fctidu` or `fctiduz` -* `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`] - -[mode `Mode`]: #fpr-to-gpr-conversion-mode - -## FP to Integer Conversion Pseudo-code - -Key for pseudo-code: - -| term | result type | definition | -|---------------------------|-------------|----------------------------------------------------------------------------------------------------| -| `fp` | -- | `f32` or `f64` (or other types from SimpleV) | -| `int` | -- | `u32`/`u64`/`i32`/`i64` (or other types from SimpleV) | -| `uint` | -- | the unsigned integer of the same bit-width as `int` | -| `int::BITS` | `int` | the bit-width of `int` | -| `uint::MIN_VALUE` | `uint` | the minimum value `uint` can store: `0` | -| `uint::MAX_VALUE` | `uint` | the maximum value `uint` can store: `2^int::BITS - 1` | -| `int::MIN_VALUE` | `int` | the minimum value `int` can store : `-2^(int::BITS-1)` | -| `int::MAX_VALUE` | `int` | the maximum value `int` can store : `2^(int::BITS-1) - 1` | -| `int::VALUE_COUNT` | Integer | the number of different values `int` can store (`2^int::BITS`). too big to fit in `int`. | -| `rint(fp, rounding_mode)` | `fp` | rounds the floating-point value `fp` to an integer according to rounding mode `rounding_mode` | - -
-OpenPower conversion semantics (section A.2 page 999 (page 1023) of OpenPower ISA v3.1): - -``` -def fp_to_int_open_power(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](https://docs.oracle.com/javase/specs/jls/se16/html/jls-5.html#jls-5.1.3) -/ -[Rust semantics](https://doc.rust-lang.org/reference/expressions/operator-expr.html#semantics) -(with adjustment to add non-truncate rounding modes): - -``` -def fp_to_int_java(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](https://262.ecma-international.org/11.0/#sec-toint32) (with adjustment to add non-truncate rounding modes): - -``` -def fp_to_int_java_script(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 -``` - -- 2.30.2