From: lkcl Date: Tue, 22 Dec 2020 03:12:33 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1061 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=5794cad5e9f66ced04784d47b063e2deb30c2e41;p=libreriscv.git --- diff --git a/openpower/sv/svp_rewrite/svp64.mdwn b/openpower/sv/svp_rewrite/svp64.mdwn index 8512debdd..554ef4eb5 100644 --- a/openpower/sv/svp_rewrite/svp64.mdwn +++ b/openpower/sv/svp_rewrite/svp64.mdwn @@ -40,21 +40,6 @@ v3.0/1B instructions covered by the prefix are "unaltered". This is termed `scal Note that this is completely different from when VL=0. VL=0 turns all operations under its influence into `nops` (regardless of the prefix) whereas when VL=1 and the SV prefix is all zeros, the operation simply acts as if SV had not been applied at all to the instruction (an "identity operation"). -# XER, SO and other global flags - -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. - -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 sxalar ISA. Instead, both carry-in and carry-out go into the CR.so bit of a given Vector element. - # Register Naming and size @@ -504,6 +489,21 @@ but select different *bits* of the same CRs # Appendix +## XER, SO and other global flags + +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. + +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. + ## v3.0B/v3.1B relevant instructions SV is primarily designed for use as an efficient hybrid 3D GPU / VPU / CPU ISA.