From: lkcl Date: Tue, 22 Dec 2020 05:02:33 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1051 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=9e3baedf2f75b21b7649431a8ee744db91131b50;p=libreriscv.git --- diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn index 7b7577c1c..3e25674e1 100644 --- a/openpower/sv/svp_rewrite/svp64.mdwn +++ b/openpower/sv/svp_rewrite/svp64.mdwn @@ -493,14 +493,14 @@ Vector systems are expected to be high performance. This is achieved through parallelism, which requires that elements in the vector be independent. XER SO and other global "accumulation" flags (CR.OV) cause Read-Write Hazards on single-bit global resources, having a significant -detrimental adverse effect. +detrimental effect. Consequently in SV, XER.SO and CR.OV behaviour is disregarded. XER is simply neither read nor written. This includes when `scalar identity behaviour` occurs. If precise OpenPOWER v3.0/1 scalar behaviour is desired then OpenPOWER v3.0/1 instructions should be used without an SV Prefix. An interesting side-effect of this decision is that the OE flag is now free for other uses when SV Prefixing is used. -Regarding XER.CA: this does not fit either: it was designed for a scalar ISA. Instead, both carry-in and carry-out go into the CR.so bit of a given Vector element. This provides a means to perform large parallel batches of Vectorised carry-capable additions. +Regarding XER.CA: this does not fit either: it was designed for a scalar ISA. Instead, both carry-in and carry-out go into the CR.so bit of a given Vector element. This provides a means to perform large parallel batches of Vectorised carry-capable additions. crweird instructions can be used to transfer the CRs in and out of an integer, where bitmanipulation may be performed to analyse the carry bits (including carry lookahead propagation) before continuing with further parallel additions. ## v3.0B/v3.1B relevant instructions