From: lkcl Date: Sun, 5 Jun 2022 11:23:23 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~1949 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=0b0abce355fa72d264015432afb8dd591e7c0e57;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index b4618ad1e..a9f4c6f75 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -27,15 +27,17 @@ 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. 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 +that when elwidth=8 in the Prefix it's an *8-bit* add-with-carry. +In other words, elwidth overrides **definitely** do not fundamentally +alter the actual +Scalar v3.0 ISA encoding itself. 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. +for example, and under absolutely no circumstances do the actual 32-bit +Scalar v3.0 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