(no commit message)
[libreriscv.git] / openpower / sv / ls010 / hypothetical_addi.mdwn
1 # Example demonstration instruction modified to SVP64 (badly)
2
3 <!-- hide -->
4 Background: <https://bugs.libre-soc.org/show_bug.cgi?id=1056#c12>
5 <!-- show -->
6
7 Although split-fields are used in PO1-Prefixing, and it is reasonable
8 to expect to clarify "in-situ" the behaviour of `{MLS:D-form}`
9 instructions as opposed to `{D-Form}` instructions, there are reasons
10 why doing the same for PO9-Prefixed SV instructions is neither safe
11 nor sensible. These are illustrated through a hypothetically-proposed
12 extension to `addi` / `paddi` (Public v3.1 I 3.3.9 p76).
13
14 * Firstly in SV, it is prohibited from adding new operands.
15 `addi RT,RA,SI` may **only** be extended to `sv.addi RT,RA,SI`.
16 * Secondly, the field positions and bits are also prohibited from
17 being changed merely because of a PO9-Prefix.
18 * Thirdly, just because of the PO9-Prefix it is prohibited to
19 put an entirely different instruction into the Suffix position.
20 If `{PO14}` as a 32-bit instruction is defined as "addi", then
21 it is **required** that `{PO9}-{PO14}` **be** a Vectorized "addi",
22 **not** a Vectorized multiply.
23 * Fourthly, where PO1-Prefixing of operand fields (often resulting
24 in "split field" redefinitions such as `si0||si1`) is an arbitrary
25 manually-hand-crafted procedure,
26 SV's entire PO9-Prefixing of Register Fields is **fully-automated**
27 i.e. RISC-paradigm uniform and regular.
28 * Fifthly, the "unclean" exposure of SV concepts directly into the RTL
29 creates a massive "unreadability" problem. you can't actually find
30 the "add" in amongst all the "operand cruft", and Saturation,
31 Sub-Vectors, Element-width Overrides, Predication, REMAP, all have
32 not been introduced yet!
33
34
35 **Add Immediate** D-Form
36
37 * addi RT,RA,SI
38
39 ```
40 DWI:
41 | 14 | RT | RA | SI |
42 | 0 | 6 | 11 | 16 31 |
43 ```
44
45 **Prefixed Add Immediate** MLS:D-form
46
47 * paddi RT,RA,SI,R
48
49 ```
50 Prefix:
51 | 1 | 2 | 0 | // | R | // | si0 |
52 | 0 | 6 | 8 | 9 | 11 | 12 | 14 31 |
53
54 Suffix::
55 | 14 | RT | RA | si1 |
56 | 0 | 6 | 11 | 16 31 |
57 ```
58
59 **Vectorized Add Immediate** SVRM-Normal:D-form
60
61 * sv.addi RT,RA,SI
62
63 ```
64 Prefix:
65 | 9 | .. | Stuff | EXTRA | MODEBITS |
66 | 0 | 6 | 8 | 17 26 | 27 31 |
67 Suffix:
68 | 14 | RT | RA | SI |
69 | 0 | 6 | 11 | 16 31 |
70 ```
71
72 Pseudo-code:
73
74 ```
75 if "addi" then
76 RT <- (RA|0) + EXTS64(SI)
77 if "paddi" & R=0 then
78 RT <- (RA|0) + EXTS64(si0||si1)
79 if "paddi" & R=1 then
80 RT <- CIA + EXTS64(si0||si1)
81 if "sv.addi" then # beginning of spec writer nightmare
82 # spec writer's worst nightmare unfolds here
83 svra <- DECODE_WITH_EXTRA3(Suffix.D-Form.RA, EXTRA[0:2])
84 svrt <- DECODE_WITH_EXTRA3(Suffix.D-Form.RT, EXTRA[3:5])
85 svsi <- Suffix.D-Form.SI
86 # finally got to the actual add which is exactly the same as "addi"
87 # but we still have to elements and elwidth overrides *and* REMAP
88 # *and* predication and god knows what else, none of which is at
89 # all appropriate to put *here*. this *should* just be like "addi":
90 # svrt <- (svra|0) + EXTS64(SI)
91 src <- ELEMENT_FROM_GPR(svra|0, SVSTATE.srcstep, REMAP, Prefix.ELWIDTH)
92 result <- src + EXTS64(svsi)
93 ELEMENT_OF_GPR(svrt, SVSTATE.dststep, REMAP, Prefix.ELWIDTH) <- result
94 ```
95
96 Special Registers Altered:
97
98 None
99