From: lkcl Date: Thu, 2 Jun 2022 20:26:21 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2005 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=8960a3d54d70c0f463d514647a7aea4777ffe171;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 7284a2147..f95cb992c 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -26,11 +26,16 @@ The modification caveat in (2) above semantically exempts element width overrides, which still do not actually modify the meaning of the instruction: an add remains an add, even if its override makes it an 8-bit add rather than -a 64-bit add. elwidth overrides *definitely* do not alter the actual -Scalar v3.0 ISA encoding itself. -Other "modifications" such as saturation or Data-dependent Fail-First -likewise are post-augmentation or post-analysis, and do not actually -fundamentally change an add operation into a subtract for example. +a 64-bit add. Even add-with-carry remains an add-with-carry: it's just +that it's an *8-bit* add-with-carry. +In other words, elwidth overrides *definitely* do not alter the actual +Scalar v3.0 ISA encoding itself, and consequently we can still, in +the strictest sense, not be breaking rule (2). +Likewise, other "modifications" such as saturation or Data-dependent +Fail-First likewise are actually post-augmentation or post-analysis, and do +not fundamentally change an add operation into a subtract +for example, and under absolutely no circumstances do the actual +operand field bits change or the number of operands change. *(In an early Draft of SVP64, an experiment was attempted, to modify LD-immediate instructions