(no commit message)

diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn
index 6b1ca3fde2928669a728a0be52e42f0c38d207e6..9cf93f38d40ed7b8ba50e005a457d8af96d782a2 100644 (file)
--- 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**