* [[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
* 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
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) (FIXME: disagrees with int_fp_mv and int_fp_mv/appendix). None of them are strictly
-necessary but performance and power consumption may be (or, is already)
-compromised
+(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:
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,