From: lkcl Date: Fri, 3 Jun 2022 13:56:44 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2001 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=284dd477d9f72585a34428a258dae32e8464c344;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 2c47674f0..984347082 100644 --- 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.