(no commit message)

[libreriscv.git] / openpower / sv.mdwn

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index e4ecb0652a0bbbbbe3ef5421050732a83deb34dc..23b9e811b5641af5f37dc558f0e0a4f80e51dd79 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -136,6 +136,7 @@ Pages being developed and examples
   introducing new areas EXT232-63 and EXT300-363
 * [[sv/svp64]] contains the packet-format *only*, the [[svp64/appendix]]
   contains explanations and further details
+* [[sv/svp64-single]] still under development
 * [[sv/svp64_quirks]] things in SVP64  that slightly break the rules
   or are not immediately apparent despite the RISC paradigm
 * [[opcode_regs_deduped]] autogenerated table of SVP64 decoder augmentation
@@ -442,18 +443,6 @@ would become a whopping 96-bit long instruction. Avoiding this
 situation is a high priority which in turn by necessity puts pressure
 on the 32-bit Major Opcode space.
 
-SVP64 itself is already under pressure, being only 24 bits.  If it is
-not permitted to take up 25% of EXT001 then it would have to be proposed
-in its own Major Opcode, which on first consideration would be beneficial
-for SVP64 due to the availability of 2 extra bits.
-However when combined with the bitmanip scalar instructions
-requiring two Major opcodes this would come to a grand total of 3 precious
-Major opcodes. On balance, then, sacrificing 25% of EXT001 is the "least
-difficult" choice.
-Alternative locations for SVP64
-Prefixing include EXT006 and EXT017, with EXT006 being most favourable
-as there is room for future expansion.
-
 Note also that EXT022, the Official Architectural Sandbox area
 available for "Custom non-approved purposes" according to the Power
 ISA Spec,