From 0b0abce355fa72d264015432afb8dd591e7c0e57 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 5 Jun 2022 12:23:23 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) 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 -- 2.30.2