From: Luke Kenneth Casson Leighton Date: Wed, 12 Apr 2023 12:27:45 +0000 (+0100) Subject: whitespace X-Git-Tag: opf_rfc_ls010_v1~56 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=124c8e48949b4cd487b63c181750ba89a2587fd1;p=libreriscv.git whitespace --- diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn index 99e545418..671f2e5e6 100644 --- a/openpower/sv/rfc/ls012.mdwn +++ b/openpower/sv/rfc/ls012.mdwn @@ -36,11 +36,11 @@ no guiding overview or pre-filtering, and everybody's precious time 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 @@ -50,16 +50,16 @@ high-priority for Audio/Video, Vector GPU and HPC Workloads, but has 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 @@ -97,35 +97,35 @@ Audio/Visual, High-Performance Compute, GPU workloads and DSP. * 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 @@ -133,17 +133,16 @@ These without question have to go in EXT0xx. Future extended variants, 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. @@ -173,8 +172,8 @@ when 3D Graphics simply has no need for full accuracy. ## 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 @@ -274,9 +273,9 @@ as just one example. 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 @@ -344,9 +343,9 @@ LD L1/2/3 D-Cache memory-lookup operation, by virtue of the Immediate 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 @@ -393,11 +392,11 @@ offset computation, thus they are best placed in EXT0xx. 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. @@ -410,11 +409,12 @@ source code)* 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 @@ -427,20 +427,20 @@ becomes a candidate for Vector-Prefixing. This in turn means that when 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. -------- @@ -451,8 +451,8 @@ and a huge responsibility. In public standards mistakes are irrevocable, 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?** @@ -591,8 +591,8 @@ The above helps explain the columns in the tables that follow. The original tables are available publicly as as CSV file at . -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: