From: Jacob Lifshay Date: Wed, 22 Mar 2023 21:55:18 +0000 (-0700) Subject: copy changes from ls006 -> int_fp_mv -- table changes are a separate commit X-Git-Tag: opf_rfc_ls001_v3~101 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e3b729aed995b32f6a530e500a85480470f36752;p=libreriscv.git copy changes from ls006 -> int_fp_mv -- table changes are a separate commit --- diff --git a/openpower/sv/int_fp_mv.mdwn b/openpower/sv/int_fp_mv.mdwn index 6cc707985..523929c36 100644 --- a/openpower/sv/int_fp_mv.mdwn +++ b/openpower/sv/int_fp_mv.mdwn @@ -303,12 +303,18 @@ File to another. 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. +Special Registers altered: + + CR1 (if Rc=1) + ### Assembly Aliases | Assembly Alias | Full Instruction | @@ -333,11 +339,18 @@ 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. +Special Registers altered: + + CR1 (if Rc=1) + ### Assembly Aliases | Assembly Alias | Full Instruction | @@ -372,8 +385,7 @@ as exceptions. src <- bfp_CONVERT_FROM_UI32((RB)[32:63]) FRT <- bfp64_CONVERT_FROM_BFP(src) else - # rounding may be necessary - # based off xscvuxdsp + # rounding may be necessary. based off xscvuxdsp reset_xflags() switch(IT) case(0): # Signed 32-bit @@ -401,14 +413,24 @@ as exceptions. FPSCR.FR <- inc_flag 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. - -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. +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. Rc=1 tests FRT and sets CR1, exactly like all other Scalar Floating-Point operations. +Special Registers altered: + + CR1 (if Rc=1) + FPCSR (TODO: which bits?) (if IT[0] != 0 or RCS[0] != 0) + ### Assembly Aliases | Assembly Alias | Full Instruction | @@ -434,30 +456,38 @@ operations.
-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 long/int results) + [FP -> Integer conversion](https://docs.oracle.com/javase/specs/jls/se16/html/jls-5.html#jls-5.1.3) + (only for long/int results) * Rust's FP -> Integer conversion using the [`as` operator](https://doc.rust-lang.org/reference/expressions/operator-expr.html#semantics) * LLVM's @@ -474,7 +504,10 @@ Those same semantics are used in some way by all of the following languages (not **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 @@ -507,7 +540,8 @@ Key for pseudo-code: | `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 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(v: fp) -> int: @@ -539,7 +573,8 @@ OpenPower conversion semantics (section A.2 page 1009 (page 1035) of Power ISA v
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(v: fp) -> int: @@ -563,7 +598,6 @@ Section 7.1 of the ECMAScript / JavaScript ``` # based on xscvdpuxws reset_xflags() - if RCS[0] = 1 then # if Single mode src <- bfp_CONVERT_FROM_BFP32(SINGLE((FRB))) else @@ -621,12 +655,10 @@ Section 7.1 of the ECMAScript / JavaScript result <- si64_CONVERT_FROM_BFP(range_max) default: # JavaScript semantics # CVM = 6, 7 are illegal instructions - - # this works because the largest type we try to - # convert from has 53 significand bits, and the - # largest type we try to convert to has 64 bits, - # and the sum of those is strictly less than the - # 128 bits of the intermediate result. + # this works because the largest type we try to convert from has + # 53 significand bits, and the largest type we try to convert to + # has 64 bits, and the sum of those is strictly less than the 128 + # bits of the intermediate result. limit <- bfp_CONVERT_FROM_UI128([1] * 128) if IsInf(rnd) or IsNaN(rnd) then result <- [0] * 64 @@ -667,17 +699,24 @@ Section 7.1 of the ECMAScript / JavaScript 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. -`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. +Special Registers altered: + + CR0 (if Rc=1) + XER SO, OV, OV32 (if OE=1) + FPCSR (TODO: which bits?) ### Assembly Aliases