From: lkcl <lkcl@web>
Date: Thu, 2 Jun 2022 11:05:10 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~2018
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=2a57603ce5482dbd364c1c2b205dbbe80bc4ac02;p=libreriscv.git

---

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index b9dda69cc..b68c3168f 100644
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -79,7 +79,15 @@ overrides make absolutely no sense whatsoever. Therefore the elwidth
 override field bits can be used for other purposes when Vectorising
 CR Field instructions.  Moreover, Rc=1 is completely invalid for
 CR operations such as `crand`: Rc=1 is for arithmetic operations, producing
-a "co-result" that goes into CR0 or CR1.
+a "co-result" that goes into CR0 or CR1. Thus, the Arithmetic modes
+such as predicate-result make no sense, and neither does Saturation.
+All of these differences, which require quite a lot of logical
+reasoning and deduction, help explain why there is an entirely different
+CR ops Vectorisation Category.
+
+LOAD/STORE is another area that has different needs: this time it is
+down to limitations in Scalar LD/ST. Vector ISAs have Load/Store modes
+which simply make no sense in a RISC Scalar ISA: 
 
 # CR weird instructions