From b23c20d7695c6ab24fd708f4d31a1edccf0772fc Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 20 Apr 2022 16:55:01 +0100 Subject: [PATCH] --- openpower/sv/svp64/appendix.mdwn | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index 97cbd5d63..1e14c7748 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -21,8 +21,10 @@ independent. XER SO/OV and other global "accumulation" flags (CR.SO) cause Read-Write Hazards on single-bit global resources, having a significant detrimental effect. -Consequently in SV, XER.SO and OV behaviour is disregarded (including -in `cmp` instructions). XER is simply neither read nor written. +Consequently in SV, XER.SO behaviour is disregarded (including +in `cmp` instructions). XER.SO is not read, but XER.OV may be written, +breaking the Read-Modify-Write Hazard Chain that complicates +microarchitectural implementations. 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. @@ -31,13 +33,9 @@ TODO jacob add about OV https://www.intel.com/content/dam/www/public/us/en/docum Of note here is that XER.SO and OV may already be disregarded in the Power ISA v3.0/1 SFFS (Scalar Fixed and Floating) Compliancy Subset. -SVP64 simply makes it mandatory to disregard even for other Subsets, +SVP64 simply makes it mandatory to disregard XER.SO even for other Subsets, but only for SVP64 Prefixed Operations. -An interesting side-effect of this decision is that the OE flag is now -free for other uses when SV Prefixing is used, and CR.SO may likewise -used for other purposes (saturation for example). - XER.CA/CA32 on the other hand is expected and required to be implemented according to standard Power ISA Scalar behaviour. Interestingly, due to SVP64 being in effect a hardware for-loop around Scalar instructions -- 2.30.2