From: lkcl Date: Fri, 27 May 2022 10:07:17 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2064 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=fe2e84b8fa94f4f8eb631ca92566bedfa74c4ef1;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 404dbf564..ad3662fe6 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -5,7 +5,7 @@ SVP64 is designed around these fundamental and inviolate principles: 1. There are no actual Vector instructions: Scalar instructions are the sole exclusive bedrock. 2. No scalar instruction ever deviates in its encoding or meaning - just because it is prefixed. + just because it is prefixed (caveats below) 3. A hardware-level for-loop makes vector elements 100% synonymous with scalar instructions (the suffix) @@ -13,6 +13,14 @@ That said, there are a few exceptional places where these rules get bent, and others where the rules take some explaining, and this page tracks them. +The modification caveat obviously exempts element width overrides, +which still do not actually modify the meaning of the instruction: +an add remains an add, even if it is only an 8-bit add rather than +a 64-bit add. elwidth overrides *definitely* do not alter the 3.0 encoding. +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. + *(An experiment was attempted to modify LD-immediate instructions to include a third RC register i.e. reinterpret the normal @@ -67,3 +75,7 @@ Normally, Scalar Instructions have a good justification for being added as Scalar instructions on their own merit. `mv.x` is the polar opposite, and as such qualifies for a special mention in this section. + +# Branch-Conditional + +[[sv/branches]]