From: Jacob Lifshay <programmerjake@gmail.com>
Date: Thu, 16 Mar 2023 02:25:45 +0000 (-0700)
Subject: rename Java conversion semantics to Java/Saturating conversion semantics
X-Git-Tag: opf_rfc_ls001_v3~156
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=a44938c88e66e7d2b94b065fe0bff056a8207595;p=libreriscv.git

rename Java conversion semantics to Java/Saturating conversion semantics

since nearly everywhere else refers to it as saturating conversion
---

diff --git a/openpower/sv/int_fp_mv.mdwn b/openpower/sv/int_fp_mv.mdwn
index ff64e6654..7e97e2c5a 100644
--- a/openpower/sv/int_fp_mv.mdwn
+++ b/openpower/sv/int_fp_mv.mdwn
@@ -271,14 +271,14 @@ Tables that are used by `fmvtg`/`fmvfg`/`fcvttg`/`fcvtfg`:
 |-------|-----------------|----------------------------------|
 | 000   | from `FPSCR`    | [OpenPower semantics]            |
 | 001   | Truncate        | [OpenPower semantics]            |
-| 010   | from `FPSCR`    | [Java semantics]                 |
-| 011   | Truncate        | [Java semantics]                 |
+| 010   | from `FPSCR`    | [Java/Saturating semantics]      |
+| 011   | Truncate        | [Java/Saturating 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
+[Java/Saturating semantics]: #fp-to-int-java-saturating-conversion-semantics
 [JavaScript semantics]: #fp-to-int-javascript-conversion-semantics
 
 # Moves
@@ -453,10 +453,10 @@ OpenPOWER however has instructions for both:
 * rounding mode read from FPSCR
 * rounding mode always set to truncate
 
-**Java conversion**
+**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 conversion semantics](#fp-to-int-java-conversion-semantics).
+[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):
 
@@ -511,7 +511,7 @@ Key for pseudo-code:
 | `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):
+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:
@@ -524,8 +524,8 @@ def fp_to_int_open_power<fp, int>(v: fp) -> int:
     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)
+<div id="fp-to-int-java-saturating-conversion-semantics"></div>
+[Java/Saturating 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):
@@ -623,7 +623,7 @@ switch(CVM)
             result <- ui64_CONVERT_FROM_BFP(range_max)
         else  # Signed 32/64-bit
             result <- si64_CONVERT_FROM_BFP(range_max)
-    case(2, 3):  # Java semantics
+    case(2, 3):  # Java/Saturating semantics
         if IsNaN(rnd) then
             result <- [0] * 64
         else if bfp_COMPARE_GT(rnd, range_max) then