bug 1034: update spec page on bin/tern lut2/lut3

[libreriscv.git] / openpower / sv.mdwn

diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn
index 0523ed0408f494478d4cac0dd6aa3ece4d1ce340..23b9e811b5641af5f37dc558f0e0a4f80e51dd79 100644 (file)
--- a/openpower/sv.mdwn
+++ b/openpower/sv.mdwn
@@ -83,7 +83,7 @@ Comparative instruction count:
 * ARM NEON SIMD: around 2,000 instructions, prerequisite: ARM Scalar.
 * ARM SVE: around 4,000 instructions, prerequisite: NEON and ARM Scalar 
 * ARM SVE2: around 1,000 instructions, prerequisite: SVE, NEON, and
-  ARM Scalar
+  ARM Scalar for a grand total of well over 7,000 instructions.
 * Intel AVX-512: around 4,000 instructions, prerequisite AVX, AVX2,
   AVX-128 and AVX-256 which in turn critically rely on the rest of
   x86, for a grand total of well over 10,000 instructions.
@@ -132,8 +132,11 @@ Pages being developed and examples
 * [[sv/compliancy_levels]] for minimum subsets through to Advanced
   Supercomputing.
 * [[sv/implementation]] implementation planning and coordination
+* [[sv/po9_encoding]] a new DRAFT 64-bit space similar to EXT1xx,
+  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
@@ -177,9 +180,9 @@ It requires certain guarantees to be provided.
 * Secondly, that no instruction shall change meaning to produce
   different results on different hardware (present or future).
 * Thirdly, that Scalar "defined words" (32 bit instruction
-  encodings) if Vwctorised will also always be implemented as
+  encodings) if Vectorised will also always be implemented as
   identical Scalar instructions (the sole semi-exception being
-  Vevtorised Branch-Conditional)
+  Vectorised Branch-Conditional)
 * Fourthly, that implementors are not permitted to either add
   arbitrary features nor implement features in an incompatible
   way. *(Performance may differ, but differing results are
@@ -222,10 +225,10 @@ Some of these Scalar instructions happen also designed to make
 Scalable Vector binaries more efficient, such
 as the crweird group.  Others are to bring the Scalar Power ISA
 up-to-date within specific workloads,
-such as a Javascript Rounding instruction
-(which saves 35 instructions including 5 branches). None of them are strictly
-necessary but performance and power consumption may be (or, is already)
-compromised
+such as a JavaScript Rounding instruction
+(which saves 32 scalar instructions including seven branch instructions).
+None of them are strictly necessary but performance and power consumption may
+be (or, is already) compromised
 in certain workloads and use-cases without them.
 
 Vector-related but still Scalar:
@@ -440,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,