**Motivation**
-CPUs without VSX/VMX lack a way to efficiently transfer data between FPRs and GPRs, they need to go through memory, this proposal adds more efficient data transfer (both bitwise copy and Integer <-> FP conversion) instructions that transfer directly between FPRs and GPRs without needing to go through memory.
-
-IEEE 754 doesn't specify what results are obtained when converting a NaN or out-of-range floating-point value to integer, so different programming languages and ISAs have made different choices. Below is an overview
+CPUs without VSX/VMX lack a way to efficiently transfer data between
+FPRs and GPRs, they need to go through memory, this proposal adds more
+efficient data transfer (both bitwise copy and Integer <-> FP conversion)
+instructions that transfer directly between FPRs and GPRs without needing
+to go through memory.
+
+IEEE 754 doesn't specify what results are obtained when converting a NaN
+or out-of-range floating-point value to integer, so different programming
+languages and ISAs have made different choices. Below is an overview
of the different variants, listing the languages and hardware that
implements each variant.
RT <- (FRB)
```
-move a 32/64-bit float from a FPR to a GPR, just copying bits of the IEEE 754 representation directly. This is equivalent to `stfs` followed by `lwz` or equivalent to `stfd` followed by `ld`.
-As `fmvtg` is just copying bits, `FPSCR` is not affected in any way.
+move a 32/64-bit float from a FPR to a GPR, just copying bits of the
+IEEE 754 representation directly. This is equivalent to `stfs` followed
+by `lwz` or equivalent to `stfd` followed by `ld`. As `fmvtg` is just
+copying bits, `FPSCR` is not affected in any way.
Rc=1 tests RT and sets CR0, exactly like all other Scalar Fixed-Point
operations.
FRT <- (RB)
```
-move a 32/64-bit float from a GPR to a FPR, just copying bits of the IEEE 754 representation directly. This is equivalent to `stw` followed by `lfs` or equivalent to `std` followed by `lfd`. As `fmvfg` is just copying bits, `FPSCR` is not affected in any way.
+move a 32/64-bit float from a GPR to a FPR, just copying bits of the IEEE
+754 representation directly. This is equivalent to `stw` followed by `lfs`
+or equivalent to `std` followed by `lfd`. As `fmvfg` is just copying bits,
+`FPSCR` is not affected in any way.
Rc=1 tests FRT and sets CR1, exactly like all other Scalar Floating-Point
operations.
FPSCR.FI <- xx_flag
```
-Convert from a unsigned/signed 32/64-bit integer in RB to a 32/64-bit float in FRT, following the usual 32-bit float in 64-bit float format.
+Convert from a unsigned/signed 32/64-bit integer in RB to a 32/64-bit
+float in FRT, following the usual 32-bit float in 64-bit float format.
-If converting from a unsigned/signed 32-bit integer to a 64-bit float, rounding is never necessary, so `FPSCR` is unmodified and exceptions are never raised. Otherwise, `FPSCR` is modified and exceptions are raised as usual.
+If converting from a unsigned/signed 32-bit integer to a 64-bit float,
+rounding is never necessary, so `FPSCR` is unmodified and exceptions are
+never raised. Otherwise, `FPSCR` is modified and exceptions are raised
+as usual.
Rc=1 tests FRT and sets CR1, exactly like all other Scalar Floating-Point
operations.
<div id="fpr-to-gpr-conversion-mode"></div>
-IEEE 754 doesn't specify what results are obtained when converting a NaN or out-of-range floating-point value to integer, so different programming languages and ISAs have made different choices. Below is an overview
+IEEE 754 doesn't specify what results are obtained when converting a NaN
+or out-of-range floating-point value to integer, so different programming
+languages and ISAs have made different choices. Below is an overview
of the different variants, listing the languages and hardware that
implements each variant.
-For convenience, we will give those different conversion semantics names based on which common ISA or programming language uses them, since there may not be an established name for them:
+For convenience, we will give those different conversion semantics names
+based on which common ISA or programming language uses them, since there
+may not be an established name for them:
**Standard OpenPower conversion**
-This conversion 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:
+This conversion 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/Saturating 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/Saturating conversion semantics](#fp-to-int-java-saturating-conversion-semantics).
+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/Saturating conversion
+semantics](#fp-to-int-java-saturating-conversion-semantics).
-Those same semantics are used in some way by all of the following languages (not necessarily for the default conversion method):
+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) (only for ling/int results)
+ [FP -> Integer conversion](https://docs.oracle.com/javase/specs/jls/se16/html/jls-5.html#jls-5.1.3)
+ (only for ling/int results)
* Rust's FP -> Integer conversion using the
[`as` operator](https://doc.rust-lang.org/reference/expressions/operator-expr.html#semantics)
* LLVM'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).
+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>
| `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 1009 (page 1035) of Power ISA v3.1B):
+OpenPower conversion semantics (section A.2 page 1009 (page 1035) of
+Power ISA v3.1B):
```
def fp_to_int_open_power<fp, int>(v: fp) -> int:
<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):
+[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:
FPSCR.FI <- 0
```
-Convert from 32/64-bit float in FRB to a unsigned/signed 32/64-bit integer in RT, with the conversion overflow/rounding semantics following the chosen `CVM` value, following the usual 32-bit float in 64-bit float format.
+Convert from 32/64-bit float in FRB to a unsigned/signed 32/64-bit integer
+in RT, with the conversion overflow/rounding semantics following the
+chosen `CVM` value, following the usual 32-bit float in 64-bit float
+format.
`FPSCR` is modified and exceptions are raised as usual.
-Both of these instructions 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.
+Both of these instructions 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.
----------
projects / libreriscv.git / commitdiff