removing this page as is should never have had time wasted on it without first
authorLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 14 Mar 2023 10:25:22 +0000 (10:25 +0000)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Tue, 14 Mar 2023 10:25:22 +0000 (10:25 +0000)
discussing if the concept has alternatives or could cause harm to the Power ISA

openpower/sv/int_fp_mv_replace_fmv_with_fgrev.mdwn [deleted file]

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 (file)
index 0851eb0..0000000
+++ /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:
-
-* <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>
-* <https://bugs.libre-soc.org/show_bug.cgi?id=887> fmvis
-* <https://bugs.libre-soc.org/show_bug.cgi?id=1015> 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  <a name="fmvis"></a>
-
-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 <a name="fishmv"></a>
-
-`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
-
-<div id="fpr-to-gpr-conversion-mode"></div>
-
-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
-<https://developer.arm.com/documentation/dui0801/g/hko1477562192868>
-
-**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`      |
-
-<div id="fp-to-int-openpower-conversion-semantics"></div>
-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)
-```
-
-<div id="fp-to-int-java-conversion-semantics"></div>
-[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<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)
-```
-
-<div id="fp-to-int-javascript-conversion-semantics"></div>
-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<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
-```
-