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

---

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index ad9beddc4..90d689ca6 100644
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -104,7 +104,7 @@ RM Prefix to convey the stride mode, changing the Effective Address
 computation as a result. Interestingly, worth noting for Hardware
 designers: it did turn out to be possible to perform pre-multiplication
 of the D/DS Immediate by the stride amount, making it possible to avoid
-actually modifying the LD/ST Pipelibe itself.
+actually modifying the LD/ST Pipeline itself.
 
 Other areas where LD/ST went quirky: element-width overrides especially
 when combined with Saturation, given that LD/ST operations have byte,
@@ -113,6 +113,26 @@ widths as part of the actual operation, and the source and destination
 elwidth overrides, was particularly obtuse and hard to derive: some care
 and attention is advised, here, when reading the specification.
 
+**Non-vectorised**
+
+The concept of a Vectorised halt (`attn`) makes no sense. There are never
+going to be a Vector of global MSRs (Machine Status Register). `mtcr`
+on the other hand is a grey area: `mtspr` is clearly Vectoriseable.
+Even `td` and `tdi` makes a strange type of sense to permit it to be
+Vectorised, because a sequence of comparisons could be Vectorised.
+Vectorised System Calls (`sc`) or `tlbie` and other Cache or Virtual
+Nemory Management
+instructions, these make no sense to Vectorise.
+
+However, it is really quite important to not be tempted to conclude that
+just because these instructions are un-vectoriseable, the opcode space
+must be free for reiterpretation and use for other purposes. This would
+be a serious mistake because a future revision of the specification
+might *retire* the Scalar instruction, replace it with another.
+Again this comes down to being quite strict about the rules: only Scalar
+instructions get Vectorised: there are *no* actual explicit Vector
+instructions.
+
 # CR weird instructions
 
 [[sv/int_cr_predication]] is by far the biggest violator of the SVP64