From: Luke Kenneth Casson Leighton Date: Sun, 3 Jan 2021 19:01:09 +0000 (+0000) Subject: whitespace X-Git-Tag: convert-csv-opcode-to-binary~624 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=34f8864129d2222da386a909c4f0d3170826cc4e;p=libreriscv.git whitespace --- diff --git a/openpower/sv/propagation.mdwn b/openpower/sv/propagation.mdwn index c928f51d0..e523521ca 100644 --- a/openpower/sv/propagation.mdwn +++ b/openpower/sv/propagation.mdwn @@ -2,18 +2,31 @@ Context Propagation is for a future version of SV -[[sv/svp64]] context is 24 bits long, and Swizzle is 12. These are enormous and not sustainable as far as power consumption is concerned. Also, there is repetition of the same contexts to different instructions. An idea therefore is to add a level of indirection that allows these contexts to be applied to multiple instructions. - -The basic principle is to have a suite of 40 indices in a shift register that indicate one of seven Contexts shall be applied to upcoming 32 bit v3.0B instructions. The Least Significant Index in the shift register is the one that is applied. One of those indices is 0b000 which indicates "no prefix applied". - -A special instruction in an svp64 context takes a copy of the `RM[0..23]` bits, alongside a 21 bit suite that indicates up to 20 32 bit instructions will have that `RM` applied to them, as well as an index to associate with the `RM`. If there are already indices set within the shift register then the new entries are placed after the end of the highest-indexed one. +[[sv/svp64]] context is 24 bits long, and Swizzle is 12. These +are enormous and not sustainable as far as power consumption is +concerned. Also, there is repetition of the same contexts to different +instructions. An idea therefore is to add a level of indirection that +allows these contexts to be applied to multiple instructions. + +The basic principle is to have a suite of 40 indices in a shift register +that indicate one of seven Contexts shall be applied to upcoming 32 bit +v3.0B instructions. The Least Significant Index in the shift register is +the one that is applied. One of those indices is 0b000 which indicates +"no prefix applied". + +A special instruction in an svp64 context takes a copy of the `RM[0..23]` +bits, alongside a 21 bit suite that indicates up to 20 32 bit instructions +will have that `RM` applied to them, as well as an index to associate +with the `RM`. If there are already indices set within the shift register +then the new entries are placed after the end of the highest-indexed one. | 0.5|6.8 | 9.10|11.31| name | | -- | --- | --- | --- | ------- | | OP | MMM | | | ?-Form | | OP | 000 | idx | imm | | -Two different types of contexts are available so far: svp64 RM and swizzle. Their format is as follows when stored in SPRs: +Two different types of contexts are available so far: svp64 RM and +swizzle. Their format is as follows when stored in SPRs: | 0...4 | 5..7 | 8........31 | name | | ----- | ---- | ----------- | --------- | @@ -22,29 +35,53 @@ Two different types of contexts are available so far: svp64 RM and swizzle. Thei | 00010 | 000 | sh0-3 ms0-3 | Remap | -There are 4 64 bit SPRs used for storing Context, and the data is stored as follows: +There are 4 64 bit SPRs used for storing Context, and the data is stored +as follows: * 7 32 bit contexts are stored, each indexed from 0b001 to 0b111, 2 per 64 bit SPR and 1 in the 4th. -* Starting from bit 32 of the 4th SPR, in batches of 40 bits the Shift Registers are stored. - -When each LSB is nonzero in any one of the seven Shift Registers the corresponding Contexts are looked up and merged (ORed) together. Contexts for different purposes however may not be mixed: an illegal instruction is raised if this occurs. - -The reason for merging the contexts is so that different aspects may be applied. For example some `RM` contexts may indicate that predication is to be applied to an instruction whilst another context may contain the svp64 Mode. Combining the two allows the predication aspect to be merged and shared, making for better packing. - -These changes occur on a precise schedule: compilers should not have difficulties statically allocating the Context Propagation, as long as certain conventions are followed, such as avoidance of allowing the context to propagate through branches used by more than one incoming path, and variable-length loops. - -Loops, clearly, because if the setup of the shift registers does not precisely match the number of instructions, the meaning of those instructions will change as the bits in the shift registers run out! However if the loops are of fixed size and small enough (40 instructions maximum) then it is perfectly reasonable to insert repeated patterns into the shift registers, enough to cover all the loops. Ordinarily however the use of the Context Propagation instructions should be inside the loop and it is the responsibility of the compiler and assembler writer to ensure that the shift registers reach zero before any loop jump-back point. +* Starting from bit 32 of the 4th SPR, in batches of 40 bits the Shift + Registers are stored. + +When each LSB is nonzero in any one of the seven Shift Registers +the corresponding Contexts are looked up and merged (ORed) together. +Contexts for different purposes however may not be mixed: an illegal +instruction is raised if this occurs. + +The reason for merging the contexts is so that different aspects may be +applied. For example some `RM` contexts may indicate that predication +is to be applied to an instruction whilst another context may contain +the svp64 Mode. Combining the two allows the predication aspect to be +merged and shared, making for better packing. + +These changes occur on a precise schedule: compilers should not have +difficulties statically allocating the Context Propagation, as long +as certain conventions are followed, such as avoidance of allowing the +context to propagate through branches used by more than one incoming path, +and variable-length loops. + +Loops, clearly, because if the setup of the shift registers does +not precisely match the number of instructions, the meaning of those +instructions will change as the bits in the shift registers run out! +However if the loops are of fixed size and small enough (40 instructions +maximum) then it is perfectly reasonable to insert repeated patterns into +the shift registers, enough to cover all the loops. Ordinarily however +the use of the Context Propagation instructions should be inside the +loop and it is the responsibility of the compiler and assembler writer +to ensure that the shift registers reach zero before any loop jump-back +point. ## Pseudocode: -The internal data structures need not precisely match the SPRs. Here are some internal datastructures: +The internal data structures need not precisely match the SPRs. Here are +some internal datastructures: bit sreg[7][40] # seven 40 bit shift registers bit context[7][24] # seven contexts int sregoffs[7] # indicator where last bits were placed -The Context Propagation instruction then inserts bits into the selected stream: +The Context Propagation instruction then inserts bits into the selected +stream: count = 20-count_trailing_zeros(imm) context[idx] = new_context @@ -52,7 +89,9 @@ The Context Propagation instruction then inserts bits into the selected stream: sreg[idx][start:start+count] = imm[0:count] sregoffs[idx] += count -With each shift register being maintained independently the new bits are dropped in where the last ones end. To get which one is to be applied is as follows: +With each shift register being maintained independently the new bits are +dropped in where the last ones end. To get which one is to be applied +is as follows: apply_context for i in range(7): @@ -65,17 +104,22 @@ Note that it is the LSB that says which context is to be applied. # Swizzle Propagation -Swizzle Contexts follow the same schedule except that there is a mask for specifying to which registers the swizzle is to be applied, and there is only 17 bit suite to indicate the instructions to which the swizzle applies. +Swizzle Contexts follow the same schedule except that there is a mask +for specifying to which registers the swizzle is to be applied, and +there is only 17 bit suite to indicate the instructions to which the +swizzle applies. -The bits in rhe svp64 `RM` field are interpreted as a pair of 12 bit swizzles +The bits in rhe svp64 `RM` field are interpreted as a pair of 12 bit +swizzles | 0.5| 6.8 | 9.11| 12.14 | 15.31 | name | | -- | --- | --- | ----- | ----- | ------- | | OP | MMM | | mask | | ?-Form | | OP | 001 | idx | mask | imm | | -Note however that it is only svp64 encoded instructions -to which swizzle applies, so Swizzle Shift Registers only activate (and shift down) on svp64 instructions. *This includes Context-propagated ones!* +Note however that it is only svp64 encoded instructions to which swizzle +applies, so Swizzle Shift Registers only activate (and shift down) +on svp64 instructions. *This includes Context-propagated ones!* The mask is encoded as follows: @@ -83,21 +127,35 @@ The mask is encoded as follows: * bit 1 indicates that src2 is swizzled * bit 2 indicates that src3 is swizzled -When the compiler creates Swizzle Contexts it is important to recall that the Contexts will be ORed together. Thus one Context may specify a mask whilst the other Context specifies the swizzles: ORing different mask contexts with different swizzle Contexts allows more combinations than would normally fit into seven Contexts. +When the compiler creates Swizzle Contexts it is important to recall +that the Contexts will be ORed together. Thus one Context may specify +a mask whilst the other Context specifies the swizzles: ORing different +mask contexts with different swizzle Contexts allows more combinations +than would normally fit into seven Contexts. -More than one bit is permitted to be set in the mask: swiz1 is applied to the first src operand specified by the mask, and swiz2 is applied to the second. +More than one bit is permitted to be set in the mask: swiz1 is applied +to the first src operand specified by the mask, and swiz2 is applied to +the second. # 2D/3D Matrix Remap -*Based on the old version [[simple_v_extension/remap]], the Shape CSRs remain the same as does the algorithm that performs the remapping*. +*Based on the old version [[simple_v_extension/remap]], the Shape CSRs +remain the same as does the algorithm that performs the remapping*. -Remap allows up to four Vectors (all four arguments of `fma` for example) to be algorithmically arbitrarily remapped via 1D, 2D or 3D reshaping. +Remap allows up to four Vectors (all four arguments of `fma` for example) +to be algorithmically arbitrarily remapped via 1D, 2D or 3D reshaping. -Vectors may be remapped such that Matrix multiply of any arbitrary size is performed in one Vectorised `fma` instruction as long as the total number of elements is less than 64 (maximum for VL). +Vectors may be remapped such that Matrix multiply of any arbitrary size +is performed in one Vectorised `fma` instruction as long as the total +number of elements is less than 64 (maximum for VL). -There are four possible Shapes. Unlike swizzle contexts this one requires rhe external remap Shape SPRs because the state information is too large to fit into the Context itself. Thus the Remap Context says which Shapes apply to which registers. +There are four possible Shapes. Unlike swizzle contexts this one requires +rhe external remap Shape SPRs because the state information is too large +to fit into the Context itself. Thus the Remap Context says which Shapes +apply to which registers. -The instruction format is the same as `RM` and thus uses 21 bits of immediate, 29 of which are dropped into the indexed Shift Register +The instruction format is the same as `RM` and thus uses 21 bits of +immediate, 29 of which are dropped into the indexed Shift Register | 0.5|6.8 | 9.10|11.31| name | | -- | --- | --- | --- | ------- | @@ -110,8 +168,11 @@ Again it is the 24 bit `RM` that is interpreted differently: | ----- | ------- | | sh0-3 | mask0-3 | -The shape indices 0-3 are numbered 0-3 whilst the masks are bitmasks that indicate src or dest to which the associated shape (0-3) is to be applied. -A zero mask indicates that the Shape is not to be applied. Note that whilst the masks are unary encoded the Shape indices sh0-3 are not: this must be taken into consideration when ORing occurs. +The shape indices 0-3 are numbered 0-3 whilst the masks are bitmasks +that indicate src or dest to which the associated shape (0-3) is to +be applied. A zero mask indicates that the Shape is not to be applied. +Note that whilst the masks are unary encoded the Shape indices sh0-3 +are not: this must be taken into consideration when ORing occurs. The mask is encoded as follows: