(no commit message)

diff --git a/openpower/sv/rfc/ls016.mdwn b/openpower/sv/rfc/ls016.mdwn
index aa44445057706b9534e9df155ab417b52c20a9a7..ca45e559196c1b32d9167313f91305dca000b0bd 100644 (file)
--- a/openpower/sv/rfc/ls016.mdwn
+++ b/openpower/sv/rfc/ls016.mdwn
@@ -75,10 +75,9 @@ get efficient execution.
 **Notes and Observations**:
 
 1. Whilst it is easy to justify these high-value instructions they are
-   sufficiently complex as to warrant placement as optional SFFS in the
-   new EXT2xx area (marked as Vectoriseable).
+   sufficiently complex as to consider being optional SFFS.
 2. Although they are 3-in 2-out the actual encoding is as a double-overwrite
-   reducing the actual number of operands down to three (RT RA and RB)
+   reducing the number of operands down to three (RT RA and RB)
    where RT is a Read-Modify-Write and an additional RS (normally RT+1)
    is implicit.
 3. As with the biginteger set of 3-in 2-out instructions if Power ISA did not
@@ -95,7 +94,7 @@ get efficient execution.
    exactly the same reason that the equivalent CAS sequence may not be
    macro-op fused.  Full in-place Vectorised FFT and DCT algorithms *only*
    become possible due to these instructions atomically reading **both**
-   operands into internal Reservation Stations (exactly like CAS).
+   Butterfly operands into internal Reservation Stations (exactly like CAS).
 5. Although desirable (particularly to detect overflow) Rc=1 is hard to
    conceptualise.  It is likely that instead, Simple-V "saturation" if
    enabled will create an Rc=1 CR.SO flag (including SVP64Single).