(no commit message)

[libreriscv.git] / openpower / sv / rfc / ls005.mdwn

diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn
index f449ff4f92ca0430478901b9ffd22210677a65f1..f19cf7fc5c9f9799e98135198ee9ed1e52883a35 100644 (file)
--- a/openpower/sv/rfc/ls005.mdwn
+++ b/openpower/sv/rfc/ls005.mdwn
@@ -17,9 +17,7 @@
 
 **Date**: 22 Dec 2022
 
-**Target**: v3.2B
-
-**Source**: v3.0B
+**Target** v3.2B
 
 **Books and Section affected**:
 
@@ -99,18 +97,17 @@ whether (and how many) sequentially-grouped registers are taken together to
 create 16-bit, 32-bit and 64-bit addresses (depending on application need).
 GPR is obvious, FPR is quirky.  SVP64 redefines FP ops (those not ending in "s")
 to be "full width" and all ops ending in "s" to be "half of
-the FP width".
+the full width".
 
 * XLEN=64 keeps FPR "full width" exactly as presently defined, and
   "half width" exactly as presently defined.
 * XLEN=32 overrides FPR "full width" operations to
-  full FP32, and "half width" to be "FP16 stored in an FP32"
-* XLEN=16 redefines FPR "full width" operations to full BFP16 and leaves
-  "half width" UNDEFINED (there is no FP8).
-* XLEN=8 redefines FPR "full width" operations to BF16 and leaves
-  "half width" UNDEFINED (there is no BF8).
+  full BFP32, and "half width" to be "BFP16 stored in an BFP32"
+* XLEN=16 redefines FPR "full width" operations to full [IEEE BFP16](https://en.wikipedia.org/wiki/Half-precision_floating-point_format) and leaves
+  "half width" RESERVED (there is no IEEE version of [FP8](https://web.archive.org/web/20221223085833/https://wccftech.com/nvidia-intel-arm-bet-their-ai-future-on-fp8-whitepaper-for-8-bit-fp-published/)).
+* XLEN=8 redefines FPR "full width" operations to [bfloat16](https://en.wikipedia.org/wiki/Bfloat16_floating-point_format) and leaves
+  "half width" RESERVED. 
 
 ----------------
 
 \newpage{}
-