Sunday, 2022-04-17

ghostmansdlkcl, a question on differences between CR_3bit and CR_5bit13:04
ghostmansdon binutils side, both only have PPC_OPERAND_CR_BIT flag active13:12
ghostmansdI've checked records we have, here's the binutils part:
ghostmansdah, yeah, I see, 3-bit do have PPC_OPERAND_CR_REG flag set, that's the difference...13:14
ghostmansdOK, I think that's enough to differentiate these13:14
ghostmansdhm, an interesting note13:14
ghostmansdPPC_OPERAND_CR_REG: This is a CR FIELD that does not use symbolic names (unless -mregnames is in effect).  If both PPC_OPERAND_CR_BIT and PPC_OPERAND_CR_REG are set then treat the field as per PPC_OPERAND_CR_BIT for assembly, but as if neither of these bits are set for disassembly.13:15
ghostmansdInterestingly enough, we do have _one_ instruction which has both flags: #define BTF BT + 113:17
ghostmansd  { 0x1f, 21, NULL, NULL, PPC_OPERAND_CR_BIT | PPC_OPERAND_CR_REG },13:17
ghostmansd`/* The BT field in a mtfsb0 or mtfsb1 instruction.  */`13:17
ghostmansdlkcl, for the record, I consider the dynamic changing of `extras' dict from `(0, '5.v', 'RT', 'GPR', None)' to `5' a real cheating!13:48
ghostmansdhad to spend a lot of time to understand what happens there, and still investigate it in details13:48
lkclghostmansd, sorry, just saw this14:19
ghostmansdthat's OK, most of it was again mumbling to myself until the stuff is clear :-D14:19
lkclalso remember, there's no CR ops done (yet)14:20
ghostmansdreally that's magic self-solving chat14:20
lkclhey we could sell it as the cheapest AI chat product and make a fortune14:20
ghostmansdit's amazing that, creating a totally unrelated stuff, we found such gem14:22
ghostmansdI bet that, regardless of whatever we invent here, the real treasure is already found14:23
lkclBT conversion, mentally, is awful.16:17
lkclfirst you have to convert in your head to the fact that CRs are 32-bit but CR *fields* are 4-bit16:18
lkcltherefore, BT is 5-bit (just like RT, RA etc.) but the top 3 bits refer to the CR *field* number, and the bottom 2 bits refer to either EQ/LT/GT/SO *of* the CR field.16:19
lkclSVP64 applies to CR *Field* numbers, so you must do the SVP64 extra on the *top 3 bits* of BT16:20
lkclbut leave the bottom 2 bits of BT completely untouched.16:20
lkclit doesn't help that the numbering of CR Fields is inverted (MSB0 numbering)16:20
* lkcl bangs head against desk repeatedly to stop the pain16:21
lkclCR{n} refers to CR0 when n=0 and consequently, for CR0-7, is defined, in v3.0B pseudocode, as:16:21
lkcl   CR{7-n} = CR[32+n*4:35+n*4]16:21
* lkcl laughs manically16:22
lkclghostmansd[m], you'll find the algorithm listed out in full in Section "CR EXTRA mapping table and algorithm"16:23
lkclhappy easter everyone18:08
lkclhappy {insert-pagan-festival-of-choice}18:09
lkclfrickin awesome website
ghostmansdlkcl, a quick question on FieldSelectableInt: what happens to gaps in list?19:43
ghostmansdI mean, I think I understand what happens if we have a consecutive range, like `self.major = FieldSelectableInt(self.insn, tuple(range(0, 6)))'19:44
ghostmansdbut what happens here?19:44
ghostmansdrmfields = [6, 8] + list(range(10, 32))  # SVP64 24-bit RM (ReMap)19:44
ghostmansdself.rm = FieldSelectableInt(self.insn, rmfields)19:44
ghostmansdbit 9... what happens to it? I kinda got lost in the woods of SelectableInt, BitRange, __init__ and eq19:45
ghostmansdAs I get, BitRange is a simple mapping of bits, where each bit has some value mapped... e.g. given record (8, 10) on input, this would give {0: 8, 1: 10}19:50
ghostmansdBut, at the same time, I assumed that `self.major = FieldSelectableInt(self.insn, tuple(range(0, 6)))' grabs bits 0..5 inclusive19:52
ghostmansdall in all, I've been thinking that FieldSelectableInt simply "slices" bits, that is, `major' corresponds to bits 0..5 inclusively, and affecting `major' changes `insn' as well, so that _its_ bits 0..5 inclusively get changed20:02
ghostmansdbut this gap, I don't understand how it works20:02
ghostmansdOK, I think I got it... FieldSelectableInt maps bits exactly as they are present:  [6, 8] go to 0, 1, then 10..32 go to 2..1420:16
ghostmansdI totally missed that `self.major' has _range_, not a simple (0,6), damn20:17
ghostmansdAh yeah, it won't be that easy as I initially imagined... ok, never surrender.20:22
ghostmansd(here's how I imagined it initially:
ghostmansdok, never mind, I'll come with something more creative20:22
ghostmansdanyway, your suggestions are welcome :-)20:23
ghostmansd[m]One thing I'm completely sure of: no, there won't be fully-blown SelectableInt stuff in binutils, sorry for getting your hopes up20:32
lkclghostmansd[m], sorry, not in front of the computer, but checking occasionally22:07
lkclSelectableInt is a way in python to select (and set) individual bits on an integer... *in MSB0 order*22:08
lkclFieldSelectableInt is a wrapper that allows *subsets* of a SelectableInt to be *arbitrarily* selected... oh and arithmetic to be performed on the *underlying* SelectableInt, as if they were contiguous bits22:09
lkclso the example you gave was bits22:09
lkcl(because range (10,32) ==> 10..31 inclusive in python)22:09
lkcland the mapping is:22:09
lkclFSInt bit 0 --> 622:09
lkclFSInt bit1 --> 822:10
lkclFSInt bit 2 --> 1022:10
lkclFSInt bit 3 --> 1122:10
lkcletc. etc.22:10
lkclit doesn't "slice", it's "a level of indirection"22:10
lkclthe reason i created it was because Power ISA has all sorts of borked-ness when it comes to accessing bits within instructions.22:11
lkclthe 6-bit SH field of the rlwimi (or rldicl something-or-other) has bit 0-4 of SH being in 15-20, but bit 5 of SH is in 31 or something odd22:11
lkcland i thought, "this is nuts, let's make it easy by creating a class that reconstructs SH=FieldSelectableInt([15,16,17,18,19,31], opcode)22:12
lkclso as you don't have that in c, you'll have to come up with some way to reconstruct the fields.22:13
lkcland probably simply do it with mask set/get... yeah like in that pastebin22:14
lkclSV RM would be22:15
lkclsvp64_field_get(field, 6,7) | (svp64_field_get(field, 8,9)<<1) | (svp64_field_get(field, 10,32)<<2)22:16
lkclsomething like that22:16

Generated by 2.17.1 by Marius Gedminas - find it at!