From: Luke Kenneth Casson Leighton Date: Sun, 4 Jun 2023 14:46:13 +0000 (+0100) Subject: move hypothetical_add and trial_add to correct directory X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e632f1ba1ddb9a7a78978837f5a5fe404d7dedd9;p=libreriscv.git move hypothetical_add and trial_add to correct directory --- diff --git a/openpower/sv/ls010/hypothetical_addi.mdwn b/openpower/sv/ls010/hypothetical_addi.mdwn deleted file mode 100644 index 66e52a458..000000000 --- a/openpower/sv/ls010/hypothetical_addi.mdwn +++ /dev/null @@ -1,99 +0,0 @@ -# Example demonstration instruction modified to SVP64 (badly) - - -Background: - - -Although split-fields are used in PO1-Prefixing, and it is reasonable -to expect to clarify "in-situ" the behaviour of `{MLS:D-form}` -instructions as opposed to `{D-Form}` instructions, there are reasons -why doing the same for PO9-Prefixed SV instructions is neither safe -nor sensible. These are illustrated through a hypothetically-proposed -extension to `addi` / `paddi` (Public v3.1 I 3.3.9 p76). - -* Firstly in SV, it is prohibited from adding new operands. - `addi RT,RA,SI` may **only** be extended to `sv.addi RT,RA,SI`. -* Secondly, the field positions and bits are also prohibited from - being changed merely because of a PO9-Prefix. -* Thirdly, just because of the PO9-Prefix it is prohibited to - put an entirely different instruction into the Suffix position. - If `{PO14}` as a 32-bit instruction is defined as "addi", then - it is **required** that `{PO9}-{PO14}` **be** a Vectorized "addi", - **not** a Vectorized multiply. -* Fourthly, where PO1-Prefixing of operand fields (often resulting - in "split field" redefinitions such as `si0||si1`) is an arbitrary - manually-hand-crafted procedure, - SV's entire PO9-Prefixing of Register Fields is **fully-automated** - i.e. RISC-paradigm uniform and regular. -* Fifthly, the "unclean" exposure of SV concepts directly into the RTL - creates a massive "unreadability" problem. you can't actually find - the "add" in amongst all the "operand cruft", and Saturation, - Sub-Vectors, Element-width Overrides, Predication, REMAP, all have - not been introduced yet! - - -**Add Immediate** D-Form - -* addi RT,RA,SI - -``` - DWI: - | 14 | RT | RA | SI | - | 0 | 6 | 11 | 16 31 | -``` - -**Prefixed Add Immediate** MLS:D-form - -* paddi RT,RA,SI,R - -``` - Prefix: - | 1 | 2 | 0 | // | R | // | si0 | - | 0 | 6 | 8 | 9 | 11 | 12 | 14 31 | - - Suffix:: - | 14 | RT | RA | si1 | - | 0 | 6 | 11 | 16 31 | -``` - -**Vectorized Add Immediate** SVRM-Normal:D-form - -* sv.addi RT,RA,SI - -``` - Prefix: - | 9 | .. | Stuff | EXTRA | MODEBITS | - | 0 | 6 | 8 | 17 26 | 27 31 | - Suffix: - | 14 | RT | RA | SI | - | 0 | 6 | 11 | 16 31 | -``` - -Pseudo-code: - -``` - if "addi" then - RT <- (RA|0) + EXTS64(SI) - if "paddi" & R=0 then - RT <- (RA|0) + EXTS64(si0||si1) - if "paddi" & R=1 then - RT <- CIA + EXTS64(si0||si1) - if "sv.addi" then # beginning of spec writer nightmare - # spec writer's worst nightmare unfolds here - svra <- DECODE_WITH_EXTRA3(Suffix.D-Form.RA, EXTRA[0:2]) - svrt <- DECODE_WITH_EXTRA3(Suffix.D-Form.RT, EXTRA[3:5]) - svsi <- Suffix.D-Form.SI - # finally got to the actual add which is exactly the same as "addi" - # but we still have to elements and elwidth overrides *and* REMAP - # *and* predication and god knows what else, none of which is at - # all appropriate to put *here*. this *should* just be like "addi": - # svrt <- (svra|0) + EXTS64(SI) - src <- ELEMENT_FROM_GPR(svra|0, SVSTATE.srcstep, REMAP, Prefix.ELWIDTH) - result <- src + EXTS64(svsi) - ELEMENT_OF_GPR(svrt, SVSTATE.dststep, REMAP, Prefix.ELWIDTH) <- result -``` - -Special Registers Altered: - - None - diff --git a/openpower/sv/ls010/trial_addi.mdwn b/openpower/sv/ls010/trial_addi.mdwn deleted file mode 100644 index e5a19d870..000000000 --- a/openpower/sv/ls010/trial_addi.mdwn +++ /dev/null @@ -1,71 +0,0 @@ -# Example demonstration instruction modified to SVP64 (better) - - -Background: - - -**Add Immediate** D-Form - -* addi RT,RA,SI - -``` - Defined Word-instruction: - | 14 | RT | RA | SI | - | 0 | 6 | 11 | 16 31 | -``` - -* Operand RTL.RA <- `D-Form.RA` -* Operand RTL.RT <- `D-Form.RT` -* Operand RTL.SI <- `D-Form.SI` - -**Prefixed Add Immediate** MLS:D-form - -* paddi RT,RA,SI,R - -``` - Prefix: - | 1 | 2 | 0 | // | R | // | si0 | - | 0 | 6 | 8 | 9 | 11 | 12 | 14 31 | - - Suffix:: - | 14 | RT | RA | si1 | - | 0 | 6 | 11 | 16 31 | -``` - -* Operand RTL.RA <- `D-Form.RA` -* Operand RTL.RT <- `D-Form.RT` -* Operand RTL.SI <- `MLS.si0 || MLS.si1` - -**Vectorized Add Immediate** SVP64-RM-1S1D/EXTRA3/Normal:D-form - -* sv.addi RT,RA,SI - -``` - Prefix: - | 9 | .. | Stuff | EXTRA | MODEBITS | - | 0 | 6 | 8 | 17 26 | 27 31 | - Defined Word-instruction: - | 14 | RT | RA | SI | - | 0 | 6 | 11 | 16 31 | -``` - -* Operand RTL.RA <- `SVP64_EXTRA3_DECODE(D-Form.RA, SVP64.RM.EXTRA[0:2])` -* Operand RTL.RT <- `SVP64_EXTRA3_DECODE(D-Form.RA, SVP64.RM.EXTRA[3:5])` -* Operand RTL.SI <- `D-Form.SI` - -Pseudo-code: - -``` - if "addi" then - RT <- (RA|0) + EXTS64(SI) - if "paddi" & R=0 then - RT <- (RA|0) + EXTS64(si0||si1) - if "paddi" & R=1 then - RT <- CIA + EXTS64(si0||si1) - -``` - -Special Registers Altered: - - None - diff --git a/openpower/sv/rfc/ls010/hypothetical_addi.mdwn b/openpower/sv/rfc/ls010/hypothetical_addi.mdwn new file mode 100644 index 000000000..66e52a458 --- /dev/null +++ b/openpower/sv/rfc/ls010/hypothetical_addi.mdwn @@ -0,0 +1,99 @@ +# Example demonstration instruction modified to SVP64 (badly) + + +Background: + + +Although split-fields are used in PO1-Prefixing, and it is reasonable +to expect to clarify "in-situ" the behaviour of `{MLS:D-form}` +instructions as opposed to `{D-Form}` instructions, there are reasons +why doing the same for PO9-Prefixed SV instructions is neither safe +nor sensible. These are illustrated through a hypothetically-proposed +extension to `addi` / `paddi` (Public v3.1 I 3.3.9 p76). + +* Firstly in SV, it is prohibited from adding new operands. + `addi RT,RA,SI` may **only** be extended to `sv.addi RT,RA,SI`. +* Secondly, the field positions and bits are also prohibited from + being changed merely because of a PO9-Prefix. +* Thirdly, just because of the PO9-Prefix it is prohibited to + put an entirely different instruction into the Suffix position. + If `{PO14}` as a 32-bit instruction is defined as "addi", then + it is **required** that `{PO9}-{PO14}` **be** a Vectorized "addi", + **not** a Vectorized multiply. +* Fourthly, where PO1-Prefixing of operand fields (often resulting + in "split field" redefinitions such as `si0||si1`) is an arbitrary + manually-hand-crafted procedure, + SV's entire PO9-Prefixing of Register Fields is **fully-automated** + i.e. RISC-paradigm uniform and regular. +* Fifthly, the "unclean" exposure of SV concepts directly into the RTL + creates a massive "unreadability" problem. you can't actually find + the "add" in amongst all the "operand cruft", and Saturation, + Sub-Vectors, Element-width Overrides, Predication, REMAP, all have + not been introduced yet! + + +**Add Immediate** D-Form + +* addi RT,RA,SI + +``` + DWI: + | 14 | RT | RA | SI | + | 0 | 6 | 11 | 16 31 | +``` + +**Prefixed Add Immediate** MLS:D-form + +* paddi RT,RA,SI,R + +``` + Prefix: + | 1 | 2 | 0 | // | R | // | si0 | + | 0 | 6 | 8 | 9 | 11 | 12 | 14 31 | + + Suffix:: + | 14 | RT | RA | si1 | + | 0 | 6 | 11 | 16 31 | +``` + +**Vectorized Add Immediate** SVRM-Normal:D-form + +* sv.addi RT,RA,SI + +``` + Prefix: + | 9 | .. | Stuff | EXTRA | MODEBITS | + | 0 | 6 | 8 | 17 26 | 27 31 | + Suffix: + | 14 | RT | RA | SI | + | 0 | 6 | 11 | 16 31 | +``` + +Pseudo-code: + +``` + if "addi" then + RT <- (RA|0) + EXTS64(SI) + if "paddi" & R=0 then + RT <- (RA|0) + EXTS64(si0||si1) + if "paddi" & R=1 then + RT <- CIA + EXTS64(si0||si1) + if "sv.addi" then # beginning of spec writer nightmare + # spec writer's worst nightmare unfolds here + svra <- DECODE_WITH_EXTRA3(Suffix.D-Form.RA, EXTRA[0:2]) + svrt <- DECODE_WITH_EXTRA3(Suffix.D-Form.RT, EXTRA[3:5]) + svsi <- Suffix.D-Form.SI + # finally got to the actual add which is exactly the same as "addi" + # but we still have to elements and elwidth overrides *and* REMAP + # *and* predication and god knows what else, none of which is at + # all appropriate to put *here*. this *should* just be like "addi": + # svrt <- (svra|0) + EXTS64(SI) + src <- ELEMENT_FROM_GPR(svra|0, SVSTATE.srcstep, REMAP, Prefix.ELWIDTH) + result <- src + EXTS64(svsi) + ELEMENT_OF_GPR(svrt, SVSTATE.dststep, REMAP, Prefix.ELWIDTH) <- result +``` + +Special Registers Altered: + + None + diff --git a/openpower/sv/rfc/ls010/trial_addi.mdwn b/openpower/sv/rfc/ls010/trial_addi.mdwn new file mode 100644 index 000000000..e5a19d870 --- /dev/null +++ b/openpower/sv/rfc/ls010/trial_addi.mdwn @@ -0,0 +1,71 @@ +# Example demonstration instruction modified to SVP64 (better) + + +Background: + + +**Add Immediate** D-Form + +* addi RT,RA,SI + +``` + Defined Word-instruction: + | 14 | RT | RA | SI | + | 0 | 6 | 11 | 16 31 | +``` + +* Operand RTL.RA <- `D-Form.RA` +* Operand RTL.RT <- `D-Form.RT` +* Operand RTL.SI <- `D-Form.SI` + +**Prefixed Add Immediate** MLS:D-form + +* paddi RT,RA,SI,R + +``` + Prefix: + | 1 | 2 | 0 | // | R | // | si0 | + | 0 | 6 | 8 | 9 | 11 | 12 | 14 31 | + + Suffix:: + | 14 | RT | RA | si1 | + | 0 | 6 | 11 | 16 31 | +``` + +* Operand RTL.RA <- `D-Form.RA` +* Operand RTL.RT <- `D-Form.RT` +* Operand RTL.SI <- `MLS.si0 || MLS.si1` + +**Vectorized Add Immediate** SVP64-RM-1S1D/EXTRA3/Normal:D-form + +* sv.addi RT,RA,SI + +``` + Prefix: + | 9 | .. | Stuff | EXTRA | MODEBITS | + | 0 | 6 | 8 | 17 26 | 27 31 | + Defined Word-instruction: + | 14 | RT | RA | SI | + | 0 | 6 | 11 | 16 31 | +``` + +* Operand RTL.RA <- `SVP64_EXTRA3_DECODE(D-Form.RA, SVP64.RM.EXTRA[0:2])` +* Operand RTL.RT <- `SVP64_EXTRA3_DECODE(D-Form.RA, SVP64.RM.EXTRA[3:5])` +* Operand RTL.SI <- `D-Form.SI` + +Pseudo-code: + +``` + if "addi" then + RT <- (RA|0) + EXTS64(SI) + if "paddi" & R=0 then + RT <- (RA|0) + EXTS64(si0||si1) + if "paddi" & R=1 then + RT <- CIA + EXTS64(si0||si1) + +``` + +Special Registers Altered: + + None +