is wasted. Also note that the Libre-SOC Team, being funded by NLnet
under Privacy and Enhanced Trust Grants, are **prohibited** from signing
Commercial-Confidentiality NDAs, as doing so is a direct conflict of
-interest with their funding body's Charitable Foundation Status and
-remit, and therefore the **entire** set of almost 150 new SFFS instructions
+interest with their funding body's Charitable Foundation Status and remit,
+and therefore the **entire** set of almost 150 new SFFS instructions
can only go via the External RFC Process. Also be advised and aware
-that "Libre-SOC" != "RED Semiconductor Ltd". The two are completely **separate**
-organisations*.
+that "Libre-SOC" != "RED Semiconductor Ltd". The two are completely
+**separate** organisations*.
Worth bearing in mind during evaluation that every "Defined Word" may
or may not be Vectoriseable, but that every "Defined Word" should have
less merit as a Scalar-only operation, yet when SVP64Single-Prefixed
can be part of an atomic Compare-and-Swap sequence.
-Although one of the top world-class ISAs,
-Power ISA Scalar (SFFS) has not been significantly advanced in 12
-years: IBM's primary focus has understandably been on PackedSIMD VSX.
-Unfortunately, with VSX being 914 instructions and 128-bit it is far too
-much for any new team to consider (10+ years development effort) and far
-outside of Embedded or Tablet/Desktop/Laptop power budgets. Thus bringing
-Power Scalar up-to-date to modern standards *and on its own merits*
-is a reasonable goal, and the advantages of the reduced focus is that
-SFFS remains RISC-paradigm, with lessons being be learned from other
-ISAs from the intervening years. Good examples here include `bmask`.
+Although one of the top world-class ISAs, Power ISA Scalar (SFFS) has
+not been significantly advanced in 12 years: IBM's primary focus has
+understandably been on PackedSIMD VSX. Unfortunately, with VSX being
+914 instructions and 128-bit it is far too much for any new team to
+consider (10+ years development effort) and far outside of Embedded or
+Tablet/Desktop/Laptop power budgets. Thus bringing Power Scalar up-to-date
+to modern standards *and on its own merits* is a reasonable goal, and
+the advantages of the reduced focus is that SFFS remains RISC-paradigm,
+with lessons being be learned from other ISAs from the intervening years.
+Good examples here include `bmask`.
SVP64 Prefixing - also known by the terms "Zero-Overhead-Loop-Prefixing"
as well as "True-Scalable-Vector Prefixing" - also literally brings new
* 25 - Transcendentals (2-arg) [[openpower/transcendentals]]
Summary tables are created below by different sort categories. Additional
-columns (and tables) as necessary can be requested to be added as part of update revisions
-to this RFC.
+columns (and tables) as necessary can be requested to be added as part
+of update revisions to this RFC.
\newpage{}
# Target Area summaries
-Please note that there are some instructions developed thanks to NLnet
-funding that have not been included here for assessment. Examples
+Please note that there are some instructions developed thanks to
+NLnet funding that have not been included here for assessment. Examples
include `pcdec` and the Galois Field arithmetic operations. From a purely
practical perspective due to the quantity the lower-priority instructions
were simply left out. However they remain in the Libre-SOC resources.
Some of these SFFS instructions appear to be duplicates of VSX.
-A frequent argument comes up that if instructions
-are in VSX already they should not be added to SFFS, especially if
-they are nominally the same. The logic that this effectively damages
-performance of an SFFS-only implementation was raised earlier, however
-there is a more subtle reason why the instructions are needed.
+A frequent argument comes up that if instructions are in VSX already they
+should not be added to SFFS, especially if they are nominally the same.
+The logic that this effectively damages performance of an SFFS-only
+implementation was raised earlier, however there is a more subtle reason
+why the instructions are needed.
Future versions of SVP64 and SVP64Single are expected to be developed
by future Power ISA Stakeholders on top of VSX. The decisions made
-there about the meaning of Prefixed Vectorised VSX may be **completely**
-different from those made for Prefixed SFFS instructions. At which
-point the lack of SFFS equivalents would penalise SFFS implementors
-in a much more severe way, effectively expecting them and SFFS programmers
-to work with a non-orthogonal paradigm, to their detriment.
-The solution is to give the SFFS Subset the space and respect that it deserves
-and allow it to be stand-alone on its own merits.
+there about the meaning of Prefixed Vectorised VSX may be *completely
+different* from those made for Prefixed SFFS instructions. At which
+point the lack of SFFS equivalents would penalise SFFS implementors in a
+much more severe way, effectively expecting them and SFFS programmers to
+work with a non-orthogonal paradigm, to their detriment. The solution
+is to give the SFFS Subset the space and respect that it deserves and
+allow it to be stand-alone on its own merits.
## SVP64 Management instructions
bringing even more powerful capabilities, can be followed up later with
EXT1xx prefixed variants, which is not possible if placed in EXT2xx.
*Only `svstep` is actually Vectoriseable*, all other Management
-instructions are UnVectoriseable. PO1-Prefixed examples include adding
-psvshape in order to support both Inner and Outer Product Matrix
+instructions are UnVectoriseable. PO1-Prefixed examples include
+adding psvshape in order to support both Inner and Outer Product Matrix
Schedules, by providing the option to directly reverse the order of the
-triple loops. Outer is used for standard Matrix Multiply (on top
-of a standard MAC or FMAC instruction), but Inner is
-required for Warshall Transitive Closure (on top of a cumulatively-applied
-max instruction).
+triple loops. Outer is used for standard Matrix Multiply (on top of a
+standard MAC or FMAC instruction), but Inner is required for Warshall
+Transitive Closure (on top of a cumulatively-applied max instruction).
The Management Instructions themselves are all Scalar Operations, so
-PO1-Prefixing is perfectly reasonable. SVP64 Management instructions of
-which there are only 6 are all 5 or 6 bit XO, meaning that the opcode
+PO1-Prefixing is perfectly reasonable. SVP64 Management instructions
+of which there are only 6 are all 5 or 6 bit XO, meaning that the opcode
space they take up in EXT0xx is not alarmingly high for their intrinsic
strategic value.
## Audio/Video
Found at [[sv/av_opcodes]] these do not require Saturated variants
-because Saturation is added via [[sv/svp64]] (Vector Prefixing) and via
-[[sv/svp64_single]] Scalar Prefixing. This is important to note for
+because Saturation is added via [[sv/svp64]] (Vector Prefixing) and
+via [[sv/svp64_single]] Scalar Prefixing. This is important to note for
Opcode Allocation because placing these operations in the UnVectoriseable
areas would irredeemably damage their value. Unlike PackedSIMD ISAs
the actual number of AV Opcodes is remarkably small once the usual
These LUT2/3 operations are high cost high reward. Outlined in
[[sv/bitmanip]], the simplest ones already exist in PackedSIMD VSX:
`xxeval`. The same reasoning applies as to fclass: SFFS needs to be
-stand-alone on its own merits and should an implementor
-choose not to implement any aspect of PackedSIMD VSX the performance
-of their product should not be penalised for making that decision.
+stand-alone on its own merits and should an implementor choose not to
+implement any aspect of PackedSIMD VSX the performance of their product
+should not be penalised for making that decision.
With Predication being such a high priority in GPUs and HPC, CR Field
variants of Ternary and Binary LUT instructions were considered high
FP value being in the I-Cache side. It is such a high priority that
these instructions are easily justifiable adding into EXT0xx, despite
requiring a 16-bit immediate. By designing the second-half instruction
-as a Read-Modify-Write it saves on XO bit-length (only 5 bits), and can be
-macro-op fused with its first-half to store a full IEEE754 FP32 immediate
-into a register.
+as a Read-Modify-Write it saves on XO bit-length (only 5 bits), and
+can be macro-op fused with its first-half to store a full IEEE754 FP32
+immediate into a register.
There is little point in putting these instructions into EXT2xx. Their
very benefit and inherent value *is* as 32-bit instructions, not 64-bit
Also included because it is important to see the quantity of instructions:
LD/ST-Indexed-Shifted. Across Update variants, Byte-reverse variants,
-Arithmetic and FP, the total is a slightly-eye-watering **37** instructions,
-only ameliorated by the fact that they are all 9-bit XO. The upside as
-far as adding them is concerned is that existing hardware will already
-have amalgamated pipelines with very few actual back-end (Micro-Coded)
-internal operations (likely just two: one load, one store).
+Arithmetic and FP, the total is a slightly-eye-watering **37**
+instructions, only ameliorated by the fact that they are all 9-bit XO.
+The upside as far as adding them is concerned is that existing hardware
+will already have amalgamated pipelines with very few actual back-end
+(Micro-Coded) internal operations (likely just two: one load, one store).
Passing a 2-bit additional immediate field down to those pipelines really
is not hard.
To be submitted as part of [[ls001]], [[ls008]], [[ls009]] and [[ls010]],
with SVP64Single to follow in a subsequent RFC, SVP64 is conceptually
-identical to the 50+ year old 8080 `REP` instruction and the Zilog Z80
-`CPIR` and `LDIR` instructions. Parallelism is best achieved by exploiting
-a Multi-Issue Out-of-Order Micro-architecture. It is extremely important
-to bear in mind that at no time does SVP64 add even one single actual
-Vector instruction. It is a *pure* RISC-paradigm Prefixing concept only.
+identical to the 50+ year old 8080 `REP` instruction and the Zilog
+Z80 `CPIR` and `LDIR` instructions. Parallelism is best achieved
+by exploiting a Multi-Issue Out-of-Order Micro-architecture. It is
+extremely important to bear in mind that at no time does SVP64 add even
+one single actual Vector instruction. It is a *pure* RISC-paradigm
+Prefixing concept only.
This has some implications which need unpacking. Firstly: in the future,
the Prefixing may be applied to VSX. The only reason it was not included
a new instruction is proposed, it becomes a hard requirement to consider
not only the implications of its inclusion as a Scalar-only instruction,
but how it will best be utilised as a Vectorised instruction **as well**.
-Extreme examples of this are the Big-Integer 3-in 2-out instructions that
-use one 64-bit register effectively as a Carry-in and Carry-out. The
+Extreme examples of this are the Big-Integer 3-in 2-out instructions
+that use one 64-bit register effectively as a Carry-in and Carry-out. The
instructions were designed in a *Scalar* context to be inline-efficient
-in hardware (use of Operand-Forwarding to reduce the chain down to 2-in 1-out),
-but in a *Vector* context it is extremely straightforward to Micro-code
-an entire batch onto 128-bit SIMD pipelines, 256-bit SIMD pipelines, and
-to perform a large internal Forward-Carry-Propagation on for example the
-Vectorised-Multiply instruction.
+in hardware (use of Operand-Forwarding to reduce the chain down to 2-in
+1-out), but in a *Vector* context it is extremely straightforward to
+Micro-code an entire batch onto 128-bit SIMD pipelines, 256-bit SIMD
+pipelines, and to perform a large internal Forward-Carry-Propagation on
+for example the Vectorised-Multiply instruction.
Thirdly: as far as Opcode Allocation is concerned, SVP64 needs to be
considered as an independent stand-alone instruction (just like `REP`).
-In other words, the Suffix **never** gets decoded as a completely different
-instruction just because of the Prefix. The cost of doing so is simply
-too high in hardware.
+In other words, the Suffix **never** gets decoded as a completely
+different instruction just because of the Prefix. The cost of doing so
+is simply too high in hardware.
--------
and in the case of an ISA the Opcode Allocation is a finite resource,
meaning that mistakes punish future instructions as well. This section
therefore provides some Evaluation Guidance on the decision process,
-particularly for people new to ISA development, given that this RFC
-is circulated widely and publicly. Constructive feedback from experienced
+particularly for people new to ISA development, given that this RFC is
+circulated widely and publicly. Constructive feedback from experienced
ISA Architects welcomed to improve this section.
**Does anyone want it?**
The original tables are available publicly as as CSV file at
<https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls012/optable.csv;hb=HEAD>.
-A python program auto-generates the tables in the following sections
-by sorting into different useful priorities.
+A python program auto-generates the tables in the following sections by
+sorting into different useful priorities.
The key to headings and sections are as follows:
projects / libreriscv.git / commitdiff