* 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.
* [[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
a "feature"*. Explained in <https://m.youtube.com/watch?v=HNEm8zmkjBU>
it is the exact same binary-incompatibility issue faced by Power ISA
on its 32- to 64-bit transition: 32-bit hardware was **unable** to
-trap-and-emulate 64-bit binarues because the opcodes were (are) the same.
+trap-and-emulate 64-bit binaries because the opcodes were (are) the same.
It is therefore *guaranteed* that extensions to the register file
width and quantity in Simple-V shall only be made in future by
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:
* [[sv/fclass]] detect class of FP numbers
* [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
* [[sv/av_opcodes]] scalar opcodes for Audio/Video
+* [[prefix_codes]] Decode/encode prefix-codes, used by JPEG, DEFLATE, etc.
* TODO: OpenPOWER adaptation [[openpower/transcendentals]]
Twin targetted instructions (two registers out, one implicit, just like
* *even Unvectoriseable* "Defined Words" (`mtmsr`) must have the
corresponding SVP64 Prefixed Space `RESERVED`, permanently requiring
- Illegal Instruction to be raised (the 64-bit encoding allocated
- to `sv.mtmsr` if illegally attempted must be **defined** to
- raise an Exception)
+ Illegal Instruction to be raised (the 64-bit encoding corresponding
+ to an illegal `sv.mtmsr` if ever incorrectly attempted must be
+ **defined** to raise an Exception)
* *Even instructions that may not be Scalar* (although for various
- practical reasons this is extremely rare if not impossible)
+ practical reasons this is extremely rare if not impossible,
+ if not just generally "strongly discouraged")
which have no meaning or use as a 32-bit Scalar "Defined Word", **must**
still have the Scalar "Defined Word" `RESERVED` in the scalar
opcode space, as an Illegal Instruction.
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,
projects / libreriscv.git / blobdiff