From: lkcl <lkcl@web>
Date: Fri, 5 May 2023 00:49:13 +0000 (+0100)
Subject: (no commit message)
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f83f5ca2582c46d2df4d080dcb3719af0a517e58;p=libreriscv.git

---

diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn
index 6b1ca3fde..9cf93f38d 100644
--- a/openpower/sv/rfc/ls012.mdwn
+++ b/openpower/sv/rfc/ls012.mdwn
@@ -646,7 +646,27 @@ instruction do too much.
 Another good example is the Integer Twin-butterfly instructions,
 `((a +/- b) * c) >> sh` which require **eight** instructions and
 temporary registers. Although expensive they save so many other
-instructions it is hard to disregard them.
+instructions - and registers - that it is hard to disregard them
+even if their internal implementation is Micro-coded.
+
+**Is it general-purpose or have a compelling use-case?**
+
+The more specialised the instruction the less power used but the less
+opportunity it has for being used elsewhere.  Good examples of bad
+instructions are illustrated by an MSc proposing a chacha20 SIMD add-xor-rotate-by-7
+instruction, when chacha20 has nowhere near the decades-established use as Rijndael
+(AES) or SHA. Although the instruction halved the number of inline-unrolled
+instructions in chacha20 it is clearly so specific as to be useless for any other purpose.
+
+Good examples of good specialist instructions are the
+AES and SHA round-acceleration instructions in VSX, because these algorithms
+are so heavily used that nearly all ISAs have them.
+
+Perhaps this point should be placed first but it is a different angle on
+the cost-benefit analysis that starts with "Does anyone want it": that
+alone is not quite enough, because although a given Stakeholder might want
+a particular instruction to accelerate *their* application, the expression
+of need is only where the evaluation process *begins*.
 
 **Summary**