(no commit message)

diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn
index 2c47674f00a5e497434add07d4d604d2b3e5cfa7..98434708255b9d24752df57a46f4795b0392c4ef 100644 (file)
--- a/openpower/sv/svp64_quirks.mdwn
+++ b/openpower/sv/svp64_quirks.mdwn
@@ -335,3 +335,18 @@ This is not exactly a violation of SVP64 Rules, more of a breakage
 of user expectations, particularly for LD/ST where exceptions
 would normally be expected to be raised, Fail-First provides for
 avoidance of those exceptions.
+
+# OE=1
+
+The hardware cost of Sticky Overflow in a parallel environment is immense.
+The SFFS Compliancy Level is permitted optionally to support XER.SO.
+Therefore the decision is made to make it mandatory **not** to
+support XER.SO. However, CR.SO *is* supported such that when Rc=1
+is set the CR.SO flag will contain only the overflow of
+the current instruction, rather than being actually "sticky".
+Hardware Out-of-Order designers will recognise and appreciate
+that the Hazards are
+reduced to Read-After-Write (RAW) and that the WAR Hazard is removed.
+
+This is sort-of a quirk and sort-of not, because the option to support
+XER.SO is already optional from the SFFS Compliancy Level.