From: lkcl <lkcl@web>
Date: Sun, 4 Jun 2023 17:21:09 +0000 (+0100)
Subject: (no commit message)
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f61a664f43dce738d91ddde396809609c84ae306;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls010/trial_addi.mdwn b/openpower/sv/rfc/ls010/trial_addi.mdwn
index a71413ba4..049cfdf97 100644
--- a/openpower/sv/rfc/ls010/trial_addi.mdwn
+++ b/openpower/sv/rfc/ls010/trial_addi.mdwn
@@ -11,6 +11,31 @@ fashion.
 The proposal is therefore to add a clear alternative "Operand namespace",
 which already has precedent from EXT1xx-Prefixed instructions.
 
+**Assembler Syntax**
+
+a danger of even declaring the existence "`sv.addi RT,RA,SI`" is the
+assumption that it is different from `addi RT,RA,SI`.  Alternative
+encodings that conflict with the Defined word-instruction (`addi`
+in this case) are flat-out **prohibited** in SVP64.
+
+**Vector/Scalar Operands**
+
+another danger - this one a permutation-explosion - exists when
+specifying which register operands are vector and which scalar:
+they all are, and they all are, independently of each other.
+this looks fine:
+
+* `sv.addi RT,RA,SI`
+* `sv.addi RT,*RA,SI`
+* `sv.addi *RT,RA,SI`
+* `sv.addi *RT,*RA,SI`
+
+but this gets massively out of hand very quickly:
+
+* `sv.fmadds FRT,FRA,FRB,FRC`
+* ...
+* ...
+* `sv.fmadds *FRT,*FRA,*FRB,*FRC`
 
 # SVP64-annotated addi instruction (prototype)