From f61a664f43dce738d91ddde396809609c84ae306 Mon Sep 17 00:00:00 2001
From: lkcl <lkcl@web>
Date: Sun, 4 Jun 2023 18:21:09 +0100
Subject: [PATCH]

---
 openpower/sv/rfc/ls010/trial_addi.mdwn | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

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)
 
-- 
2.30.2