| ghostmansd | lkcl, a question on differences between CR_3bit and CR_5bit | 13:04 |
|---|---|---|
| ghostmansd | on binutils side, both only have PPC_OPERAND_CR_BIT flag active | 13:12 |
| ghostmansd | I've checked records we have, here's the binutils part: https://pastebin.com/i5mbgQNZ | 13:12 |
| ghostmansd | ah, yeah, I see, 3-bit do have PPC_OPERAND_CR_REG flag set, that's the difference... | 13:14 |
| ghostmansd | OK, I think that's enough to differentiate these | 13:14 |
| ghostmansd | hm, an interesting note | 13:14 |
| ghostmansd | PPC_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 |
| ghostmansd | Interestingly enough, we do have _one_ instruction which has both flags: #define BTF BT + 1 | 13: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 |
| ghostmansd | lkcl, 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 |
| ghostmansd | had to spend a lot of time to understand what happens there, and still investigate it in details | 13:48 |
| lkcl | ghostmansd, sorry, just saw this | 14:19 |
| ghostmansd | that's OK, most of it was again mumbling to myself until the stuff is clear :-D | 14:19 |
| lkcl | haha | 14:19 |
| lkcl | also remember, there's no CR ops done (yet) | 14:20 |
| ghostmansd | really that's magic self-solving chat | 14:20 |
| lkcl | hey we could sell it as the cheapest AI chat product and make a fortune | 14:20 |
| ghostmansd | it's amazing that, creating a totally unrelated stuff, we found such gem | 14:22 |
| ghostmansd | I bet that, regardless of whatever we invent here, the real treasure is already found | 14:23 |
| lkcl | BT conversion, mentally, is awful. | 16:17 |
| lkcl | first you have to convert in your head to the fact that CRs are 32-bit but CR *fields* are 4-bit | 16:18 |
| lkcl | therefore, 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 |
| lkcl | SVP64 applies to CR *Field* numbers, so you must do the SVP64 extra on the *top 3 bits* of BT | 16:20 |
| lkcl | but leave the bottom 2 bits of BT completely untouched. | 16:20 |
| lkcl | it doesn't help that the numbering of CR Fields is inverted (MSB0 numbering) | 16:20 |
| * lkcl bangs head against desk repeatedly to stop the pain | 16:21 | |
| lkcl | appendix: https://libre-soc.org/openpower/sv/svp64/appendix | 16:21 |
| lkcl | CR{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 manically | 16:22 | |
| lkcl | ghostmansd[m], you'll find the algorithm listed out in full in Section "CR EXTRA mapping table and algorithm" | 16:23 |
| lkcl | happy easter everyone | 18:08 |
| lkcl | or | 18:08 |
| lkcl | happy {insert-pagan-festival-of-choice} | 18:09 |
| lkcl | frickin awesome website https://github.com/rootvc/cli-website | 18:46 |
| ghostmansd | lkcl, a quick question on FieldSelectableInt: what happens to gaps in list? | 19:43 |
| ghostmansd | I 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 |
| ghostmansd | but what happens here? | 19:44 |
| ghostmansd | rmfields = [6, 8] + list(range(10, 32)) # SVP64 24-bit RM (ReMap) | 19:44 |
| ghostmansd | self.rm = FieldSelectableInt(self.insn, rmfields) | 19:44 |
| ghostmansd | bit 9... what happens to it? I kinda got lost in the woods of SelectableInt, BitRange, __init__ and eq | 19:45 |
| ghostmansd | As 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 |
| ghostmansd | But, at the same time, I assumed that `self.major = FieldSelectableInt(self.insn, tuple(range(0, 6)))' grabs bits 0..5 inclusive | 19:52 |
| ghostmansd | all 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 changed | 20:02 |
| ghostmansd | but this gap, I don't understand how it works | 20:02 |
| ghostmansd | OK, 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..14 | 20:16 |
| ghostmansd | I totally missed that `self.major' has _range_, not a simple (0,6), damn | 20:17 |
| ghostmansd | Ah yeah, it won't be that easy as I initially imagined... ok, never surrender. | 20:22 |
| ghostmansd | (here's how I imagined it initially: https://pastebin.com/L9ETUa20) | 20:22 |
| ghostmansd | ok, never mind, I'll come with something more creative | 20:22 |
| ghostmansd | anyway, 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 up | 20:32 |
| lkcl | ghostmansd[m], sorry, not in front of the computer, but checking occasionally | 22:07 |
| lkcl | SelectableInt is a way in python to select (and set) individual bits on an integer... *in MSB0 order* | 22:08 |
| lkcl | FieldSelectableInt 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 bits | 22:09 |
| lkcl | so the example you gave was bits | 22:09 |
| lkcl | 6 | 22:09 |
| lkcl | 8 | 22:09 |
| lkcl | 10 | 22:09 |
| lkcl | 11 | 22:09 |
| lkcl | 12 | 22:09 |
| lkcl | ... | 22:09 |
| lkcl | 31 | 22:09 |
| lkcl | (because range (10,32) ==> 10..31 inclusive in python) | 22:09 |
| lkcl | and the mapping is: | 22:09 |
| lkcl | FSInt bit 0 --> 6 | 22:09 |
| lkcl | FSInt bit1 --> 8 | 22:10 |
| lkcl | FSInt bit 2 --> 10 | 22:10 |
| lkcl | FSInt bit 3 --> 11 | 22:10 |
| lkcl | etc. etc. | 22:10 |
| lkcl | it doesn't "slice", it's "a level of indirection" | 22:10 |
| lkcl | the reason i created it was because Power ISA has all sorts of borked-ness when it comes to accessing bits within instructions. | 22:11 |
| lkcl | the 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 odd | 22:11 |
| lkcl | and 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 |
| lkcl | so as you don't have that in c, you'll have to come up with some way to reconstruct the fields. | 22:13 |
| lkcl | and probably simply do it with mask set/get... yeah like in that pastebin | 22:14 |
| lkcl | SV RM would be | 22:15 |
| lkcl | svp64_field_get(field, 6,7) | (svp64_field_get(field, 8,9)<<1) | (svp64_field_get(field, 10,32)<<2) | 22:16 |
| lkcl | something like that | 22:16 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!