From: lkcl Date: Sun, 30 Apr 2023 01:19:38 +0000 (+0100) Subject: (no commit message) X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=122fca0a3a37648d1df7bcbd37db0e9ffe35105d;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls016.mdwn b/openpower/sv/rfc/ls016.mdwn index aa4444505..ca45e5591 100644 --- 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).