| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 00:02 | |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 04:39 | |
| *** yambo <yambo!~yambo@184.166.146.205> has joined #libre-soc | 04:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.249> has joined #libre-soc | 09:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.249> has quit IRC | 10:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:08 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 10:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:43 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:16 | |
| ghostmansd | A quick question, how do we differ LD/ST immediate and LD/ST indexed? | 11:16 |
|---|---|---|
| ghostmansd | I understand how we differ LD/ST and Normal and Branch; well, I do not quite understand what fits "Normal", but at least I can check Function.LDST and Function.BRANCH. | 11:17 |
| ghostmansd | Ah I see, ldst_ra_vec | 11:18 |
| ghostmansd | Fuck. ldst_ra_vec goes to in1_isvec. This goes to in1_svdec.isvec... | 11:28 |
| ghostmansd | https://libre-soc.org/openpower/sv/svp64/ | 11:46 |
| ghostmansd | Again, in all tables here, it must be obvious _what_ we index | 11:46 |
| lkcl | yes it does. ldst_ra_vec is in1_svdec.isvec, from the EXTRA table | 11:47 |
| lkcl | LD/ST immediate and LD/ST indexed are from whether the suffix is "ld/st RT,RA,RB" or whether it is "ld/st RT,IMM(RA)" something like that | 11:48 |
| lkcl | which is challenging... which is why i was suggesting, yesterday, to do two types: SVMode.LDST_IMM and SVMode.LDST_IDX | 11:49 |
| lkcl | actually i'll do that now | 11:50 |
| ghostmansd | We have these two types | 11:50 |
| lkcl | no, there's only SVMode.LDST at the moment | 11:50 |
| ghostmansd | Check inside | 11:50 |
| ghostmansd | nested classes | 11:50 |
| ghostmansd | LDSTMode.idx | 11:51 |
| ghostmansd | LDSTMode.imm | 11:51 |
| lkcl | ermermerm ahhh | 11:51 |
| ghostmansd | These are simply nested | 11:51 |
| ghostmansd | So from this point of view, the code is ready | 11:51 |
| lkcl | where the heck is it... ah found it | 11:52 |
| ghostmansd | you know what? let me just push the wip | 11:52 |
| ghostmansd | done | 11:52 |
| ghostmansd | cf. recent commit | 11:52 |
| ghostmansd | cf. line 964 | 11:52 |
| lkcl | hang on there is already LDSTMode in power_enums.py | 11:52 |
| ghostmansd | I can nest it too | 11:53 |
| ghostmansd | don't concentrate on naming | 11:53 |
| ghostmansd | as I confessed | 11:53 |
| ghostmansd | I'm terrible at that | 11:53 |
| ghostmansd | :-) | 11:53 |
| ghostmansd | cf line 964 | 11:53 |
| lkcl | this isn't a good idea. it's better to have SVMode right at the top | 11:53 |
| ghostmansd | there must be some switch which, after that line, goes down to mode.imm/mode.idx | 11:54 |
| lkcl | as it's really completely different | 11:54 |
| lkcl | yes | 11:54 |
| ghostmansd | but I'm not sure what to check | 11:54 |
| lkcl | i would greatly prefer it be power_enums SVMode | 11:54 |
| lkcl | the operation type | 11:54 |
| lkcl | i already answered | 11:55 |
| lkcl | <lkcl> LD/ST immediate and LD/ST indexed are from whether the suffix is "ld/st RT,RA,RB" or whether it is "ld/st RT,IMM(RA)" something like that | 11:55 |
| lkcl | but seriously: this is better done by sv_analysis.py | 11:56 |
| lkcl | LDSTRM-2P1S1D.csv | 11:56 |
| lkcl | lwz,LDST,,2P,EX | 11:56 |
| lkcl | --> | 11:56 |
| lkcl | lwz,LDST_IDX,,2P,EX | 11:56 |
| ghostmansd | Ah | 11:56 |
| lkcl | or | 11:56 |
| ghostmansd | So we do have it... | 11:56 |
| lkcl | actually | 11:56 |
| ghostmansd | hang on | 11:56 |
| lkcl | that one's LDST_IMM | 11:57 |
| ghostmansd | mmmm | 11:57 |
| ghostmansd | I don't even see LDST_IDX in our sources | 11:57 |
| ghostmansd | or LDST_IMM | 11:57 |
| lkcl | exactly. | 11:57 |
| ghostmansd | ? | 11:57 |
| lkcl | that's because i haven't added it yet because it was only an idea as of 10 hours ago | 11:57 |
| ghostmansd | you mean we should do it? | 11:57 |
| ghostmansd | aaaah | 11:57 |
| ghostmansd | OK then | 11:57 |
| lkcl | yes | 11:57 |
| ghostmansd | well I collect all this info | 11:58 |
| ghostmansd | from CSVs | 11:58 |
| lkcl | gimme a second | 11:58 |
| ghostmansd | so, if you provide it... | 11:58 |
| ghostmansd | ...it'll be simple to grab it | 11:58 |
| lkcl | there's a trick by looking at whether the instruction has "u" or "x" etc. in it | 11:58 |
| ghostmansd | cf. line 289 | 11:58 |
| ghostmansd | I grab SVMode | 11:59 |
| ghostmansd | in power_insn.py | 11:59 |
| * lkcl concentrating on identifying IMM vs IDX ops | 11:59 | |
| ghostmansd | so once it's already there with the hint on whether it's idx/imm... | 11:59 |
| ghostmansd | the trick is done | 11:59 |
| lkcl | lwz RT,D(RA) - no "u" or "x" - immediate | 12:01 |
| ghostmansd | I also see we have NORMAL in CSVs | 12:01 |
| ghostmansd | meanwhile I'll do it, if that's OK | 12:01 |
| lkcl | lwzu RT,D(RA) - arse | 12:01 |
| ghostmansd | :-D | 12:01 |
| lkcl | x. | 12:02 |
| lkcl | just x | 12:02 |
| lkcl | done | 12:06 |
| * lkcl going to check the table you sent last night | 12:07 | |
| lkcl | hmm hmm this | 12:08 |
| lkcl | 001SVM 1Pack/Unpack mode, SUBVL>1 | 12:08 |
| ghostmansd | lkcl, I've decoupled LD/ST IMM/IDX modes | 12:09 |
| ghostmansd | no more nesting | 12:09 |
| *** octavius <octavius!~octavius@240.147.93.209.dyn.plus.net> has joined #libre-soc | 12:09 | |
| lkcl | tends to suggest an XO-style match (sel) of the *entire* 5-bits | 12:09 |
| lkcl | that one would be "001-1" | 12:09 |
| lkcl | ack | 12:09 |
| lkcl | 000dz sznormal mode | 12:09 |
| lkcl | would be "000--" | 12:10 |
| ghostmansd | > <ghostmansd> A side note: could we call "normal" at https://libre-soc.org/openpower/sv/normal/ something else? | 12:10 |
| ghostmansd | Also this | 12:10 |
| ghostmansd | normal.normal kinda bothers | 12:10 |
| lkcl | siiigh, yeeees, but the issue is, it has to cover both arithmetic and logical | 12:10 |
| ghostmansd | simple? | 12:10 |
| lkcl | meh | 12:10 |
| ghostmansd | simple.normal | 12:10 |
| ghostmansd | or ALU? | 12:11 |
| lkcl | ahhh | 12:11 |
| lkcl | alu. | 12:11 |
| lkcl | hmmm | 12:11 |
| ghostmansd | though, it'd a bit conflict with the fact there are FP operations here... | 12:11 |
| ghostmansd | aren't they? | 12:11 |
| lkcl | arlog | 12:12 |
| lkcl | arithmetic-logical | 12:12 |
| lkcl | pronounced "AHH-log" | 12:12 |
| lkcl | needs to be quick to say | 12:12 |
| ghostmansd | :-D | 12:12 |
| lkcl | frickin 'ell that's a frickin lot of changes, sigh | 12:12 |
| ghostmansd | perhaps we can approach it from different angle | 12:13 |
| ghostmansd | hang on | 12:13 |
| ghostmansd | how about changing the second normal? | 12:13 |
| ghostmansd | normal.normal | 12:13 |
| ghostmansd | this is present in all LDSTImm, LDSTIdx and Normal | 12:13 |
| lkcl | ahh | 12:14 |
| lkcl | that would be better because otherwise i actually have to move pages around | 12:14 |
| ghostmansd | Yeah | 12:14 |
| lkcl | yes. ok. | 12:14 |
| ghostmansd | Mine impression too | 12:14 |
| lkcl | simple. | 12:14 |
| lkcl | straight | 12:14 |
| lkcl | default | 12:14 |
| ghostmansd | yeah default is good | 12:14 |
| ghostmansd | imho | 12:14 |
| ghostmansd | or simple | 12:14 |
| lkcl | ok | 12:14 |
| ghostmansd | simple is better | 12:14 |
| lkcl | ordinary | 12:14 |
| lkcl | ok | 12:14 |
| ghostmansd | default kinda might put a bone in a throat in C | 12:15 |
| lkcl | on it | 12:15 |
| lkcl | ha :) | 12:15 |
| ghostmansd | (unlikely, but still) | 12:15 |
| ghostmansd | OK if you're OK with simple I'll rename the subfields | 12:15 |
| lkcl | yes go for it | 12:16 |
| lkcl | am doing the wiki / spec | 12:16 |
| ghostmansd | done | 12:16 |
| lkcl | https://libre-soc.org/openpower/sv/normal/ page done | 12:17 |
| lkcl | https://libre-soc.org/openpower/sv/ldst/ done | 12:17 |
| lkcl | https://libre-soc.org/openpower/sv/cr_ops/ done | 12:18 |
| lkcl | branch done too | 12:19 |
| lkcl | ok all good | 12:19 |
| lkcl | RM.mode.normal.ffrc1.sel (19, 20) i'd suggest dropping all of these in favour of using "NN-N-" matching against the *entire* 5 bits | 12:20 |
| ghostmansd | mhhhhm | 12:22 |
| ghostmansd | I'm not sure what you mean | 12:22 |
| ghostmansd | here I just choose the appropriate class | 12:22 |
| lkcl | you have a "sel" embedded at several levels | 12:23 |
| ghostmansd | Ah yes, this is a quirk | 12:23 |
| lkcl | in many cases it is not enough bits | 12:23 |
| lkcl | ah ok | 12:23 |
| lkcl | RM.mode.normal.puzz.zz (22,) | 12:23 |
| lkcl | buzz.dz and puzz.sz are missing | 12:23 |
| ghostmansd | Caused by the fact that I need to explicitly keep any mode as 5-bit | 12:23 |
| ghostmansd | and, well, the simplest option is to inherit | 12:23 |
| ghostmansd | and it brings the parent class (Mode) fields | 12:24 |
| lkcl | then sel should be 5-bit | 12:24 |
| lkcl | not 2-bit | 12:24 |
| ghostmansd | the sel is something that always 2-bit | 12:24 |
| ghostmansd | all modes always have 2 bits dedicated | 12:24 |
| lkcl | so you can do "if sel matches 001-1" --> SVM Pack/Unpack mode | 12:24 |
| ghostmansd | to perform an initial matching | 12:24 |
| lkcl | it's more complicated than that. 2-bits is not enough. | 12:24 |
| ghostmansd | _initial_ | 12:24 |
| lkcl | it really does have to be a... ah :) | 12:25 |
| ghostmansd | then of course other fields come to play | 12:25 |
| ghostmansd | e.g. Rc, other mode bits... | 12:25 |
| ghostmansd | but ideally I'd like to switch later to generating these | 12:25 |
| ghostmansd | there's just way too many code | 12:25 |
| lkcl | honestly i think you'll find it's easier just to do a straight (flat) mask-match against the entire 5 bits | 12:25 |
| ghostmansd | *much | 12:25 |
| ghostmansd | yes, but this would cover one specific case | 12:25 |
| lkcl | like in the CSV files with the pattern-match | 12:25 |
| lkcl | indeed - and i think you'll find that they're all unique "one specific case(s)" | 12:26 |
| lkcl | anyway - RM.mode.normal.puzz.zz (22,) - dz and sz are missing | 12:27 |
| * lkcl afk - need to get up, walk about | 12:28 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:30 | |
| ghostmansd[m] | lkcl, ack | 12:37 |
| *** octavius <octavius!~octavius@240.147.93.209.dyn.plus.net> has quit IRC | 13:05 | |
| ghostmansd[m] | lkcl, are you OK if I teach sv_analysis.py LDST_IMM/LDST_IDX? | 13:09 |
| ghostmansd[m] | We'll also have to come up with some way to determine vector registers... We already have custom DynamicOperandGPR/DynamicOperandFPR classes, capable of disassembly. | 13:11 |
| lkcl | ghostmansd[m], already done | 13:12 |
| ghostmansd[m] | Also, I've been thinking, we should have some verbose mode, which dumps all bits | 13:12 |
| ghostmansd[m] | Wow, amazing, star | 13:12 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=9dcc997693556f962aa68125490d42a0e49ad99f | 13:13 |
| lkcl | it's real simple | 13:13 |
| lkcl | - mode = 'LDST' | 13:13 |
| lkcl | + if 'x' in insn_name: # Indexed detection | 13:13 |
| lkcl | + mode = 'LDST_IDX' | 13:13 |
| lkcl | + else: | 13:13 |
| lkcl | + mode = 'LDST_IMM' | 13:13 |
| ghostmansd[m] | Cool | 13:13 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 13:28 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.61> has joined #libre-soc | 13:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.61> has quit IRC | 13:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:42 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:53 | |
| ghostmansd | lkcl, a question on normal submodes | 14:10 |
| ghostmansd | smr (scalar mapreduce), pmr (parallel mapreduce), svmr (subvector mapreduce) and pu (pack/unpack) | 14:11 |
| ghostmansd | (I suggest to give these some names in the column, too) | 14:11 |
| ghostmansd | 00 1 0 RG scalar reduce mode (mapreduce), SUBVL=1 | 14:11 |
| ghostmansd | 00 1 1 / parallel reduce mode (mapreduce), SUBVL=1 | 14:11 |
| ghostmansd | 00 1 SVM 0 subvector reduce mode, SUBVL>1 | 14:11 |
| ghostmansd | 00 1 SVM 1 Pack/Unpack mode, SUBVL>1 | 14:11 |
| ghostmansd | Cannot be there a conflict, depending on particular RG and SVM values? | 14:12 |
| ghostmansd | that is, with RG=0, we have it the same as SVM=0 | 14:12 |
| ghostmansd | Or we perhaps should check PU bit? | 14:13 |
| ghostmansd | Is there some kind of situation like FF/PR check for Rc? | 14:14 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=898#c5 you wrote that PU is dropped, I'm removing it | 14:15 |
| ghostmansd | Ah-ha, it depends on SUBVL... | 14:23 |
| ghostmansd | and SUBVL == RM.subvl, and SUBVL=1 is RM.subvl == 0b00... | 14:25 |
| ghostmansd | OK then, I'm using this, please correct me if this crime isn't solved yet | 14:25 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:32 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 14:47 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:52 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 15:00 | |
| lkcl | ghostmansd, note.... ah yes, you noticed it needs SUBVL>1 | 15:04 |
| ghostmansd | yeah, sorry, that was false alarm :-) | 15:05 |
| ghostmansd | I'm almost done w/ this decoding | 15:05 |
| lkcl | note that *EXTRA* PU modes are removed | 15:05 |
| ghostmansd | ah-ha | 15:05 |
| ghostmansd | this is actually nice | 15:05 |
| lkcl | and that they are now a sub-mode of ldst normal etc. etc. | 15:05 |
| ghostmansd | the more I get into it the more I like it | 15:05 |
| lkcl | yes, a hell of a lot better than before | 15:05 |
| lkcl | with it being part of EXTRA it sacrificed space there | 15:05 |
| ghostmansd | that said, the whole scheme is really complicated, thanks to PPC legacy | 15:06 |
| lkcl | which actually compromised those operations quite a lot | 15:06 |
| lkcl | well, you should see other 3D GPU and Scalable Vector ISAs :) | 15:06 |
| ghostmansd | OK, point taken :-) | 15:06 |
| lkcl | https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc | 15:07 |
| lkcl | and remember ARM SVE/2 is... ~7,000 instructions because it's critically dependent on NEON? | 15:07 |
| ghostmansd | impressive | 15:09 |
| ghostmansd | OK I decided we really need the verbose mode to pysvp64dis sooner than later | 15:10 |
| ghostmansd | because, well, it'd be damn good to have exact prints for modes, dynamic operands, static operands, and so on | 15:14 |
| ghostmansd | this really gives the better impression than "go count the bits you fucker" | 15:15 |
| lkcl | haha | 15:20 |
| lkcl | indeed | 15:20 |
| lkcl | btw can you add svshape2 to binutils? | 15:22 |
| lkcl | under https://bugs.libre-soc.org/show_bug.cgi?id=911 | 15:23 |
| ghostmansd | yep, sure | 15:24 |
| ghostmansd | I also need to update one of the tests there | 15:24 |
| ghostmansd | so I need to return here | 15:24 |
| ghostmansd | as for other patches upstream... I've been thinking that I'd like to update it with new fields | 15:24 |
| ghostmansd | first, because they really deprecate this idiotic struct svp64_ctx, really eliminate it, and we can update svp64_insn immediately | 15:25 |
| ghostmansd | second... anybody will ask, "of this huge file with 3000+ lines, with all these shiny getters and setters, what do you use, exactly?" | 15:26 |
| ghostmansd | and the truth is, when I started writing that code, we had none of this, and I did everything directly (pysvp64asm-style) | 15:26 |
| ghostmansd | but, anyway, svshape2 is outside of this, so yeah, I'll add it | 15:27 |
| ghostmansd | by the way... haven't we discussed somewhat more explicit name for it? | 15:27 |
| ghostmansd | IIRC that was during last conf call | 15:27 |
| lkcl | svshape2 makes sure people are aware it's using part(s) of the space used by svshape | 16:10 |
| ghostmansd | I'm mostly concerned of 2 :-) | 16:15 |
| ghostmansd | svshape is fine | 16:15 |
| ghostmansd | https://pastebin.com/uLRLTACX | 16:20 |
| ghostmansd | Anything else we'd like to see for _word_ instructions? | 16:20 |
| ghostmansd | For SVP64-augmented, there will be way more | 16:21 |
| lkcl | pffh, looks frickin great. | 16:22 |
| lkcl | ah you want brackets on OE=1,Rc=1 btw | 16:22 |
| ghostmansd | Yeah right | 16:23 |
| lkcl | otherwise it gives the impression that OE and Rc are actual args of the operation | 16:23 |
| ghostmansd | Reconstruct how it looks in the spec | 16:23 |
| ghostmansd | yeah | 16:23 |
| ghostmansd | I think we should also print layout for static operands | 16:23 |
| ghostmansd | Just so that the users can compare it | 16:23 |
| lkcl | yes. | 16:23 |
| lkcl | oh btw you saw about target_addr, yesterday? | 16:23 |
| lkcl | sigh yes that really does need to be a custom argument | 16:24 |
| ghostmansd | am, nope | 16:24 |
| ghostmansd | Likely I missed it | 16:24 |
| ghostmansd | let me check logs | 16:24 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-09-02.log.html#t2022-09-02T17:12:05 | 16:24 |
| ghostmansd | aaah I see | 16:24 |
| ghostmansd | OK will update it | 16:25 |
| lkcl | yyep. | 16:25 |
| lkcl | there's actually quite a few hiding like that | 16:25 |
| ghostmansd | What if the first two bits are non-zero? | 16:25 |
| lkcl | that's a syntax error! | 16:26 |
| ghostmansd | Ah wait | 16:26 |
| ghostmansd | That's for asm | 16:26 |
| lkcl | try it on binutils-gas. | 16:26 |
| lkcl | yes. | 16:26 |
| ghostmansd | for disasm, we only check LI/BD field and append 0b00 | 16:26 |
| ghostmansd | OK | 16:26 |
| lkcl | LI (and BD) has to get *extracted* from target_addr by doing "target_addr>>2" | 16:26 |
| lkcl | yes correct | 16:26 |
| ghostmansd | Ah-ha | 16:27 |
| lkcl | which is why we totally missed it | 16:27 |
| ghostmansd | OK sure I'll update it after disasm | 16:27 |
| lkcl | and revert the patch i did, sigh | 16:27 |
| ghostmansd | Basically this is rolling-back 1 commit | 16:27 |
| ghostmansd | Ah yes, also mdwn | 16:27 |
| lkcl | 4 | 16:27 |
| lkcl | commit 617e5af21 | 16:28 |
| lkcl | commit 7656b425de3 | 16:28 |
| lkcl | commit 7fd42a88b | 16:28 |
| lkcl | commit 05cfb8a | 16:28 |
| ghostmansd | ack | 16:33 |
| ghostmansd | https://pastebin.com/fL6xFvvm | 16:36 |
| ghostmansd | Should be better now, I also decided to output operands in binary | 16:36 |
| ghostmansd | I'll do the same for static operands | 16:36 |
| lkcl | brilliant | 16:39 |
| lkcl | oh btw can you point me at a demo way of enumerating the full list of instructions? | 16:39 |
| lkcl | and, important bit: does the data structure contain the XO width still? | 16:39 |
| lkcl | (the information from insndb.csv) | 16:40 |
| ghostmansd | https://pastebin.com/16w1vneq | 16:40 |
| ghostmansd | we're cooler than binutils | 16:40 |
| ghostmansd | yes, 1 sec | 16:40 |
| lkcl | :) | 16:40 |
| lkcl | btw do add these as actual usage-examples (https://pastebin.com/16w1vneq) | 16:41 |
| lkcl | as little test programs | 16:41 |
| ghostmansd | from openpower.decoder.power_enums import ( | 16:42 |
| ghostmansd | find_wiki_dir as _find_wiki_dir, | 16:42 |
| ghostmansd | ) | 16:42 |
| ghostmansd | from openpower.decoder.power_insn import ( | 16:42 |
| ghostmansd | Database as _Database, | 16:42 |
| ghostmansd | ) | 16:42 |
| ghostmansd | db = _Database(_find_wiki_dir()) | 16:42 |
| ghostmansd | for insn in db: | 16:42 |
| ghostmansd | print(insn) | 16:42 |
| lkcl | eek! | 16:42 |
| lkcl | ok :) | 16:42 |
| lkcl | got it | 16:43 |
| ghostmansd | insn is of type power_insn.Record | 16:43 |
| ghostmansd | there you can descend into ppc, svp64, etc. | 16:43 |
| ghostmansd | basically it has all info I managed to collect in one place | 16:43 |
| lkcl | ahh it includes the section and the bitsel | 16:44 |
| ghostmansd | yes, sure | 16:44 |
| lkcl | ok how can i walk just insndb.csv on its own? | 16:44 |
| ghostmansd | I use these | 16:44 |
| lkcl | i need to know the csv file names and the bitwidths in advance | 16:44 |
| lkcl | (in advance of enumerating). | 16:45 |
| lkcl | i could do 2-pass sigh | 16:45 |
| ghostmansd | yes and no | 16:45 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=2f4c3fb7c51285b014d8c7e2ce148a76834aae65;hb=6145d95633bbd14d4a294bd29d59c93c2bc52a51#l1084 | 16:45 |
| ghostmansd | you'll walk insnd.csv and all CSVs mentioned there | 16:45 |
| lkcl | ok great | 16:45 |
| ghostmansd | and collect these into ppcdb | 16:45 |
| ghostmansd | but yeah this will give you PPC layer, w/o fields, SVP64 or markdown | 16:46 |
| ghostmansd | ah no | 16:46 |
| ghostmansd | you _have_ to instantiate FieldsDatabase and MdwnDatabase, too | 16:46 |
| ghostmansd | since PPC database uses these for name resolving | 16:47 |
| ghostmansd | otherwise we cannot lookup instructions like `add.` | 16:47 |
| lkcl | i need the *actual* contents of insndb.csv - the minor_xxx.csv filename - section - and the bitsel | 16:47 |
| lkcl | i'll do it as 2-pass | 16:47 |
| ghostmansd | then PPCDatabase is the best option, or simply only consider insn.ppc stuff | 16:47 |
| ghostmansd | I'd go with Database + insn.ppc | 16:48 |
| ghostmansd | other databases are not really meant to be used directly | 16:48 |
| ghostmansd | > btw do add these as actual usage-examples (https://pastebin.com/16w1vneq) | 16:52 |
| ghostmansd | what do you mean? these are simple outputs from the crap I output from gas, then cut with objcopy to raw binary, then fed to pysvp64dis | 16:53 |
| lkcl | yes, exactly. | 16:53 |
| lkcl | but i don't know that. | 16:53 |
| lkcl | i have no idea how you did that. | 16:53 |
| lkcl | therefore nobody else will, either | 16:53 |
| lkcl | some actual examples are needed because i currently have to ask you, each time, "can you please run xyz" where i honeslty don't even know what "xyz" is | 16:54 |
| lkcl | ok for now i'm going to duplicate this code | 16:56 |
| lkcl | 1092 with open(path, "r", encoding="UTF-8") as stream: | 16:56 |
| lkcl | 1093 for section in parse(stream, Section.CSV): | 16:56 |
| lkcl | 1094 path = (root / section.path) | 16:56 |
| lkcl | i need to be able to enumerate the *actual* contents of the actual insndb.csv file | 16:56 |
| lkcl | not | 16:56 |
| lkcl | enumerate *instructions* that have had the insndb.csv information *added* to them | 16:56 |
| lkcl | okaaay got it. Section instances. | 17:00 |
| lkcl | i have what i need | 17:01 |
| ghostmansd | aaaah | 17:07 |
| ghostmansd | that's what you meant | 17:07 |
| ghostmansd | yeah | 17:07 |
| lkcl | on it. | 17:07 |
| ghostmansd | sorry, difficult to switch :-) | 17:07 |
| lkcl | basically i'm going to generate a markdown table of the Power v3.1 Appendix D "Opcode Maps" | 17:07 |
| ghostmansd | neat :-) | 17:09 |
| ghostmansd | yeah that'd be handy | 17:09 |
| lkcl | programmerjake and i ran into a problem where i'd mis-designed the transcendental tables | 17:09 |
| lkcl | ok now how do i match an XO against an instruction's PPCRecord? | 17:15 |
| ghostmansd | cf. Record.opcode | 17:18 |
| ghostmansd | def opcode(self): | 17:19 |
| ghostmansd | I think this is what you want | 17:19 |
| lkcl | let me try | 17:19 |
| ghostmansd | Simply discard static operands section | 17:19 |
| ghostmansd | (if you don't need them, and you likely don't) | 17:19 |
| lkcl | excellent, got FieldsOpcodes... | 17:21 |
| lkcl | now i have to match them | 17:22 |
| ghostmansd | with int? | 17:22 |
| lkcl | yes. | 17:22 |
| ghostmansd | ((opcode.value & opcode.mask) == (key & opcode.mask)) | 17:22 |
| ghostmansd | key is your int | 17:22 |
| lkcl | and it has to work even for the list-of-opcodes | 17:22 |
| lkcl | okaay | 17:22 |
| ghostmansd | if it's a list then you will iterate | 17:23 |
| lkcl | okaaay | 17:23 |
| ghostmansd | cf. Database.__getitem__ | 17:23 |
| ghostmansd | we lookup by the opcode there | 17:23 |
| ghostmansd | by name too | 17:24 |
| lkcl | right. it's not matching correctly because FieldsOpcode contains too many bits | 17:26 |
| lkcl | [FieldsOpcode(value=0x78000004, mask=0xfc00001f)] | 17:26 |
| lkcl | i *only* want the bits that were in the original insndb.csv | 17:26 |
| lkcl | because those are the XO | 17:26 |
| lkcl | i can exclude everything else, manually, with an additional masking | 17:27 |
| ghostmansd | did you discard static operands? | 17:27 |
| ghostmansd | in def opcode at Record... | 17:27 |
| lkcl | i have no idea what they are or how to do it | 17:27 |
| ghostmansd | it does more | 17:27 |
| ghostmansd | than you need | 17:28 |
| ghostmansd | > <ghostmansd> Simply discard static operands section | 17:28 |
| lkcl | i have no idea what that means | 17:28 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=b18b7c2fc21b053acf0d6b7741ba8267016b23d8;hb=c1e2a856aa04e874bbe9d2c948bf828f4beda2af#l538 | 17:28 |
| ghostmansd | don't do stuff on line 546 | 17:29 |
| lkcl | ahh ok. | 17:29 |
| lkcl | got it. | 17:29 |
| ghostmansd | and you'll get XO I think | 17:29 |
| lkcl | yes of course, that's the major opcode. | 17:29 |
| lkcl | or i could add the major opcode in. that'd work too | 17:29 |
| ghostmansd | yep, sure | 17:29 |
| ghostmansd | "static operands" is another example of my idiotic naming :-) | 17:30 |
| lkcl | F'in A! got it! | 17:30 |
| ghostmansd | these are fields known in advance | 17:30 |
| ghostmansd | examples: Rc=1, Oe=1 | 17:30 |
| ghostmansd | they kinda act like operands... | 17:30 |
| ghostmansd | ...but are not dynamic, provided by user | 17:30 |
| lkcl | urrr they're all matching against 0x780000000 | 17:30 |
| ghostmansd | so yeah this lead to idiotic "static" name | 17:30 |
| lkcl | i obviously haven't quite got this right | 17:31 |
| ghostmansd | could you give an example? | 17:31 |
| ghostmansd | say some entry from CSV | 17:31 |
| ghostmansd | that you'd like to match | 17:31 |
| ghostmansd | and the key you use to match | 17:31 |
| lkcl | minor_31.csv | 17:31 |
| lkcl | sorry | 17:31 |
| lkcl | minor_30.csv | 17:31 |
| lkcl | 010-,SHIFT_ROT,OP_RLC,NO ,0,0,rldic,MD, | 17:32 |
| ghostmansd | minor_30.csv,30,27:30,NONE,pattern | 17:32 |
| ghostmansd | 010-,SHIFT_ROT,OP_RLC,NO ,0,0,rldic,MD, | 17:32 |
| ghostmansd | OK 1 sec | 17:32 |
| lkcl | gimme a mo to commit what i have | 17:33 |
| ghostmansd | sure | 17:33 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=e391f9b0503e18ed3f9b9878e0ce6992cb590950 | 17:34 |
| lkcl | wrong end | 17:35 |
| lkcl | argh | 17:35 |
| lkcl | i know | 17:35 |
| lkcl | (31-end) | 17:35 |
| lkcl | argh | 17:35 |
| lkcl | f*****g MSB0 order | 17:35 |
| ghostmansd | Why do you do it manually? | 17:37 |
| ghostmansd | you already have XO in section.opcode | 17:37 |
| ghostmansd | or, well, the primary part | 17:37 |
| lkcl | because i have no idea that that is there | 17:37 |
| lkcl | AttributeError: 'FieldsOpcode' object has no attribute 'XO' | 17:38 |
| ghostmansd | 1 sec | 17:38 |
| ghostmansd | section.opcode == 30 | 17:38 |
| ghostmansd | fields = [] | 17:39 |
| ghostmansd | if section.opcode: | 17:39 |
| ghostmansd | fields += [(section.opcode.value, BitSel((0, 5)))] | 17:39 |
| ghostmansd | fields += [(YOUR_VALUE_HERE, section.bitsel)] | 17:39 |
| ghostmansd | else: | 17:39 |
| ghostmansd | fields += [(YOUR_VALUE_HERE, section.bitsel)] | 17:39 |
| ghostmansd | return FieldsOpcode(fields) | 17:39 |
| ghostmansd | ^ the last line will take the parts you calculated and merge it | 17:39 |
| ghostmansd | let me dive a bit more in the script | 17:40 |
| ghostmansd | you check with insn.opcode, this is not correct if you only want to ensure XO | 17:41 |
| lkcl | getting there... | 17:41 |
| lkcl | Opcode(value=0x0000001e, mask=0x0000001e) | 17:41 |
| lkcl | that's what i need | 17:42 |
| ghostmansd | OK :-) | 17:42 |
| lkcl | including lists but that's another story | 17:42 |
| ghostmansd | isn't it what you want? | 17:45 |
| ghostmansd | fields = [] | 17:46 |
| ghostmansd | if section.opcode: | 17:46 |
| ghostmansd | fields += [(section.opcode.value, BitSel((0, 5)))] | 17:46 |
| ghostmansd | fields += [(key, section.bitsel)] | 17:46 |
| ghostmansd | else: | 17:46 |
| ghostmansd | fields += [(key, section.bitsel)] | 17:46 |
| ghostmansd | opcode_to_match = FieldsOpcode(fields) | 17:46 |
| lkcl | they're all showing value=0x1e, mask=0x1e | 17:46 |
| ghostmansd | oops, hang on | 17:46 |
| lkcl | # debug-print all opcodes first | 17:48 |
| lkcl | for insn in insns: | 17:48 |
| lkcl | opcode = insn.section.opcode | 17:48 |
| lkcl | for op in opcode: | 17:48 |
| lkcl | print ("op", insn.name, op) | 17:48 |
| lkcl | op rldicl Opcode(value=0x0000001e, mask=0x0000001e) | 17:48 |
| lkcl | op rldicr Opcode(value=0x0000001e, mask=0x0000001e) | 17:48 |
| lkcl | op rldic Opcode(value=0x0000001e, mask=0x0000001e) | 17:48 |
| ghostmansd | https://pastebin.com/mBDrnx17 | 17:49 |
| ghostmansd | - opcode = insn.opcode | 17:50 |
| ghostmansd | + opcode = FieldsOpcode(fields) | 17:50 |
| ghostmansd | but I'm not sure whether the key is valid, please check it | 17:51 |
| lkcl | willdo | 17:51 |
| ghostmansd | I haven't dive into lower upper and half and bitlen | 17:51 |
| ghostmansd | frankly thanks to SelectableInt I really don't do it manually | 17:51 |
| lkcl | ahh that's giving values 0x780000004 | 17:51 |
| lkcl | i don't want the 0x70 bit | 17:52 |
| lkcl | excellent, got it | 17:52 |
| lkcl | almost there | 17:52 |
| ghostmansd | OK keep me posted | 17:53 |
| lkcl | willdo | 17:53 |
| ghostmansd | I don't understand what happens wrt key, though | 17:54 |
| ghostmansd | but, anyway, considering that you want to check some integer with the opcode without special fields, the code above should do the trick; perhaps you need even less strict mask. | 17:54 |
| ghostmansd | Or maybe you don't need even section.opcode | 17:55 |
| ghostmansd | and only need bitsels | 17:55 |
| ghostmansd | if so, drop `fields += [(insn.section.opcode.value, BitSel((0, 5)))]` line, too | 17:55 |
| lkcl | done already | 17:55 |
| lkcl | hooo f****g rah. | 17:56 |
| lkcl | at last | 17:56 |
| lkcl | dayyymh | 17:56 |
| ghostmansd | so what was it? | 18:00 |
| lkcl | just me floundering around | 18:00 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=0b9e456fb2b9fda4a5cdd4cf0f1f6a7ab60208ea | 18:01 |
| ghostmansd | OK, was it at least MSB0? :-) | 18:01 |
| lkcl | yes. subtracting from 31-*end* | 18:01 |
| lkcl | not 31-*start* | 18:01 |
| lkcl | sigh | 18:01 |
| ghostmansd | Ah OK, I also see you didn't need section.opcode, too | 18:01 |
| ghostmansd | So at least here my guess was correct :-) | 18:02 |
| ghostmansd | OK I heavily refactored and pushed the recent updates about verbose mode | 18:08 |
| ghostmansd | I did it so that it's up to operand to determine what "verbose" means | 18:09 |
| ghostmansd | https://pastebin.com/C8Cn1Qfd | 18:11 |
| ghostmansd | check BD operand entry | 18:11 |
| ghostmansd | {00} shows the last two bits are ignored | 18:11 |
| ghostmansd | perhaps these should be expressed as .. | 18:11 |
| ghostmansd | anyway, you get the idea | 18:12 |
| lkcl | oo, that's posh that is | 18:13 |
| lkcl | remember that needs to be reverted to bc BO,BI,target_addr | 18:13 |
| lkcl | *target_addr* would be 00000000000010{00} | 18:14 |
| lkcl | BO would just be 00000000000010 | 18:14 |
| ghostmansd | Ah yeah right | 18:15 |
| ghostmansd | What should be in dump, then? If I revert the stuff it'd be simply target_addr with custom repr | 18:16 |
| ghostmansd | and I can mention BO in custom repr | 18:16 |
| lkcl | lkcl> *target_addr* would be 00000000000010{00} | 18:16 |
| lkcl | if it was there at all | 18:16 |
| ghostmansd | no I mean I understand what happens | 18:16 |
| lkcl | it'd be nice but hey | 18:16 |
| ghostmansd | I mean, how to print it better... | 18:17 |
| lkcl | yes, i meant in the dump, it'd be nice to have target_addr actually print that out | 18:17 |
| lkcl | but it wouldn't have a list of fields | 18:17 |
| lkcl | but BO would | 18:17 |
| ghostmansd | OK I'll think how to handle it | 18:17 |
| ghostmansd | we iterate over operands which come from markdown... | 18:18 |
| ghostmansd | and from markdown there must be target_addr... | 18:18 |
| ghostmansd | should we print operand from markdown, or a real field? | 18:19 |
| ghostmansd | what'd be the output you'd expect? | 18:19 |
| ghostmansd | current logic assumes stuff from markdown, but can define custom disassembly for these... | 18:19 |
| ghostmansd | what'd be the line you like? | 18:19 |
| ghostmansd | but preferably a single line | 18:19 |
| ghostmansd | not two | 18:19 |
| lkcl | oh yes. the line in the mdwn would be good | 18:20 |
| lkcl | it may be necessary at some point to actually recreate those (sigh) | 18:20 |
| ghostmansd | so, like this? | 18:21 |
| ghostmansd | target_addr 00000000000010.. [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] | 18:21 |
| ghostmansd | I'm kinda worried that it hides the real field... | 18:21 |
| lkcl | BD is also needed | 18:22 |
| lkcl | i _really meant_ | 18:22 |
| lkcl | <lkcl> *target_addr* would be 00000000000010{00} | 18:22 |
| ghostmansd | it needs refactoring then... | 18:22 |
| lkcl | as one of the lines | 18:22 |
| lkcl | *and* BD | 18:22 |
| lkcl | ah | 18:22 |
| ghostmansd | could we come up with the way that can print it in one line? | 18:22 |
| ghostmansd | both? | 18:22 |
| ghostmansd | because this can be done easily | 18:22 |
| ghostmansd | I can tune the actual print | 18:22 |
| ghostmansd | but preferrably only one line | 18:23 |
| lkcl | mm.... well, target_addr is a non-existent field | 18:23 |
| ghostmansd | yeah, agree | 18:23 |
| lkcl | but yes i see no reason why it shouldn't be on the same line | 18:23 |
| ghostmansd | OK let me play with this code a bit... | 18:23 |
| ghostmansd | BD 00000000000010{00} [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] (target_addr) | 18:28 |
| ghostmansd | how about this? | 18:28 |
| lkcl | it's target_addr that is 00000000000010{00} | 18:29 |
| ghostmansd | oh no wait | 18:29 |
| lkcl | it should be | 18:29 |
| ghostmansd | yeah | 18:29 |
| ghostmansd | target_addr >> 2 | 18:29 |
| lkcl | BD 00000000000010 | 18:29 |
| ghostmansd | and no {00} | 18:29 |
| lkcl | BD 00000000000010 [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] target_addr that is 00000000000010{00} | 18:29 |
| lkcl | yes | 18:29 |
| ghostmansd | BD 00000000000010 (target_addr >> 2) [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] | 18:31 |
| lkcl | target_addr = 00000000000010{00} | 18:31 |
| lkcl | is clearer | 18:31 |
| lkcl | or in decimal | 18:32 |
| lkcl | hmmm | 18:32 |
| ghostmansd | target_addr[:-2]? | 18:32 |
| lkcl | ah. sign-extended decimal | 18:32 |
| lkcl | it's all kinda overkill but still useful for debug | 18:32 |
| ghostmansd | ah | 18:32 |
| ghostmansd | yes, exactly | 18:32 |
| ghostmansd | I'd like that we established some conventions on these | 18:33 |
| ghostmansd | sooner than later | 18:33 |
| ghostmansd | likely this is not the only case | 18:33 |
| ghostmansd | =target_addr[0:-2] | 18:36 |
| ghostmansd | how about this? | 18:36 |
| ghostmansd | or rather (=target_addr[0:-2]) | 18:36 |
| lkcl | blurgh :) | 18:37 |
| ghostmansd | OK I'm open to suggestions :-) | 18:37 |
| lkcl | MSB0 numbering. target_addr>>2 would be better but is still not accurate due to it being sign-extended | 18:37 |
| ghostmansd | But I agree on blurgh part | 18:38 |
| lkcl | BD=111111111100 | 18:38 |
| lkcl | would result in a -ve target_addr | 18:38 |
| ghostmansd | OK, (target_addr=(BD || 0b00))? | 18:38 |
| lkcl | better | 18:39 |
| lkcl | or... if we are going for pseudocode | 18:39 |
| lkcl | target_addr=EXTS(BD||0b00) | 18:39 |
| lkcl | that'd be "accurate" | 18:39 |
| ghostmansd | Cool! Cool cool cool. | 18:39 |
| lkcl | don't have to actually calculate it - just print it | 18:39 |
| ghostmansd | BD 00000000000010 [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] (target_addr=EXTS(BD || 0b00)) | 18:42 |
| ghostmansd | I moved it to the end so that the beginning is the same for all operands | 18:43 |
| lkcl | nice | 18:43 |
| ghostmansd | that is, "{binary} {span} {hints}" | 18:43 |
| ghostmansd | OK pushed, you'll like the cheat with properties I used :-) | 18:44 |
| lkcl | argh these opcode-matchings are doing my head in | 18:45 |
| lkcl | can you take a look? | 18:45 |
| ghostmansd | yeah | 18:45 |
| lkcl | i think i have an off-by-one in binsel.start/end | 18:45 |
| lkcl | but i can't resolve it | 18:45 |
| ghostmansd | OK what code? | 18:46 |
| ghostmansd | same, power_table.py? | 18:46 |
| lkcl | yes | 18:46 |
| lkcl | i think it's just | 18:46 |
| lkcl | key = i << (30-end) # MSB0-order shift up by *end* | 18:46 |
| lkcl | rather than 31-end | 18:46 |
| ghostmansd | what's the expected output? | 18:48 |
| ghostmansd | some line which you have now, compared to one you want | 18:48 |
| lkcl | a table that *would* match that of v3.1 p1162 "Table 12" | 18:48 |
| lkcl | if it wasn't for the fact that the buggers have set a different division width :) | 18:48 |
| lkcl | they've done {1}-high bit {3)-low bits | 18:49 |
| lkcl | and i assumed the division would be equal | 18:49 |
| * lkcl head spinning need to walk aroud | 18:50 | |
| ghostmansd | cannot find the table yet | 18:52 |
| ghostmansd | Appendix E. Power ISA Instruction Set Sorted by Opcode? | 18:53 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 18:57 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 18:58 | |
| ghostmansd | Let's do it the other way round. Could you, please, explain one more time, what are you trying to achieve? Assuming you have insndb.csv, what do you want to do with it? | 19:00 |
| lkcl | appendix C | 19:02 |
| lkcl | create the tables from appendix C. | 19:02 |
| lkcl | goal: auto-create the tables from appendix C. | 19:02 |
| lkcl | give me a mo i'm adding an extra option "divpoint" | 19:03 |
| lkcl | got it | 19:05 |
| lkcl | sorry, i was looking at v3.0C | 19:06 |
| lkcl | blerk | 19:06 |
| ghostmansd | def doodle_do_table(path): | 19:06 |
| ghostmansd | db = Database(root=find_wiki_dir()) | 19:06 |
| ghostmansd | for record in db: | 19:06 |
| ghostmansd | if record.section.path.name == path: | 19:06 |
| ghostmansd | # THIS IS THE SECTION YOU NEED | 19:06 |
| ghostmansd | doodle_do_table("minor_30.csv") | 19:06 |
| ghostmansd | no need for the code where you create databases on your own, map them, etc. | 19:07 |
| ghostmansd | OK moving next... | 19:07 |
| ghostmansd | (don't really dive into details, I'll push the patch to branch) | 19:07 |
| ghostmansd | or even master, it doesn't break stuff | 19:07 |
| lkcl | yes, master branch | 19:07 |
| * lkcl afk again, can you help with the pattern-matching | 19:08 | |
| lkcl | v3.1 | 19:08 |
| lkcl | appendix D | 19:08 |
| lkcl | p1359 | 19:08 |
| lkcl | table 16 | 19:08 |
| ghostmansd | Table 16:EXT030: Extended Opcode Map for Opcode Space 0, Primary Opcode 30 (bits 27:30) | 19:09 |
| ghostmansd | OK I'm checking this | 19:09 |
| lkcl | i know. | 19:10 |
| lkcl | the multiple-entries you normally have are missing | 19:10 |
| lkcl | the table *is* correct | 19:11 |
| lkcl | but the mask is wrong | 19:11 |
| lkcl | ahhh that's it | 19:11 |
| lkcl | the mask should in some cases be 0b1d | 19:11 |
| lkcl | or sorry | 19:11 |
| lkcl | 0b1c | 19:11 |
| lkcl | 001-,SHIF ,0,rldicr,MD, | 19:11 |
| lkcl | that's definitely not supposed to be a mask of 0x1e | 19:12 |
| lkcl | it should be 0b11100 | 19:12 |
| lkcl | which is | 19:12 |
| lkcl | 0b1c | 19:12 |
| lkcl | 0x1c sorry | 19:12 |
| lkcl | and yet | 19:12 |
| lkcl | op rldicr FieldsOpcode(value=0x00000004, mask=0x0000001e) | 19:12 |
| ghostmansd | 1 sec | 19:13 |
| lkcl | got it | 19:14 |
| lkcl | it is because of fields += [(insn.ppc.opcode.value, insn.ppc.bitsel)] | 19:14 |
| lkcl | that should be | 19:14 |
| lkcl | insn.ppc.opcode.mask | 19:14 |
| lkcl | not insn.ppc.bitsel | 19:14 |
| ghostmansd | fields work with range or tuple | 19:16 |
| ghostmansd | hang on | 19:16 |
| ghostmansd | which value and mask do you expect for rldicr? | 19:20 |
| lkcl | the one that's in the CSV file | 19:28 |
| lkcl | got it! | 19:29 |
| ghostmansd | bits 0..5 are 30 | 19:29 |
| lkcl | git pull - i have it | 19:30 |
| ghostmansd | Fuck | 19:30 |
| ghostmansd | I had no idea you simply wanted vanilla PPC opcode to be compared | 19:31 |
| lkcl | yyep. | 19:31 |
| ghostmansd | note that it doesn't know about its section | 19:31 |
| ghostmansd | it's just what was in the minor_30.csv | 19:31 |
| lkcl | that's what's in the CSV file, that's what's in the Appendix Opcode Map | 19:31 |
| lkcl | yes. | 19:31 |
| ghostmansd | OK | 19:31 |
| lkcl | i have made one mistake: | 19:32 |
| lkcl | multiple entries are wiped out | 19:32 |
| ghostmansd | now to iteration | 19:32 |
| lkcl | (svshape for example) | 19:32 |
| ghostmansd | def doodle_do_table(path): | 19:33 |
| ghostmansd | insns = set() | 19:33 |
| ghostmansd | db = Database(root=find_wiki_dir()) | 19:33 |
| ghostmansd | for insn in db: | 19:33 |
| ghostmansd | if insn.section.path.name == path: | 19:33 |
| ghostmansd | insns.add(insn) | 19:33 |
| ghostmansd | doodle_do_table("minor_30.csv") | 19:33 |
| ghostmansd | This gets all instructions with the CSV you want | 19:33 |
| ghostmansd | they will be in "insn" set | 19:34 |
| lkcl | already done. | 19:34 |
| lkcl | for insn in db: | 19:34 |
| lkcl | insns[str(insn.section.path)].append(insn) | 19:34 |
| lkcl | it's basically done | 19:34 |
| ghostmansd | I know | 19:35 |
| ghostmansd | I'm speaking of approach | 19:35 |
| lkcl | the only thing that's faulty is when there's multiple instructions | 19:35 |
| ghostmansd | You don't need to create these databases on your own :-) | 19:35 |
| lkcl | i'm not bothered - i'm "done" with that. it works. | 19:35 |
| lkcl | this is a rush-hack-job | 19:35 |
| ghostmansd | OK | 19:35 |
| ghostmansd | to the faulty part | 19:35 |
| lkcl | the dictionary-by-instruction-name | 19:36 |
| ghostmansd | multiple svshape? | 19:36 |
| lkcl | yes | 19:36 |
| ghostmansd | hash them by opcode | 19:36 |
| ghostmansd | insn.ppc.opcode | 19:36 |
| ghostmansd | or don't even put them to dict and use set of insns | 19:36 |
| lkcl | they'll all still enumerate though? | 19:37 |
| ghostmansd | and find by iteration (caching if you like) | 19:37 |
| ghostmansd | that's one of the reasons why I suggest using the Database | 19:37 |
| lkcl | i *think* actually it may be ok | 19:37 |
| ghostmansd | or well, store in dict a list of records | 19:37 |
| ghostmansd | up to you how to do it | 19:37 |
| ghostmansd | this is one of the reasons for that default dict of default dict of sets | 19:38 |
| lkcl | i know. | 19:38 |
| lkcl | yep. | 19:38 |
| lkcl | got it | 19:38 |
| lkcl | sorted i think | 19:38 |
| ghostmansd | on PPC database level you're fine, until you start collecting entries on your own | 19:39 |
| ghostmansd | if you do -- it's up to you how to keep, ehem, "collisions" | 19:39 |
| lkcl | actually... just found out it isn't | 19:40 |
| lkcl | i replaced one operation rldimi 011- | 19:40 |
| lkcl | with two lines | 19:40 |
| lkcl | 0110 | 19:40 |
| lkcl | and 0111 | 19:40 |
| lkcl | ah 1 sec yep | 19:41 |
| lkcl | no it's not showing up | 19:41 |
| lkcl | hmmm | 19:41 |
| lkcl | the 2nd entry doesn't get listed | 19:43 |
| ghostmansd | ah yeah, I see... | 19:44 |
| ghostmansd | it seems I'm able to reproduce it | 19:44 |
| lkcl | ok whew | 19:44 |
| ghostmansd | ah wait | 19:44 |
| ghostmansd | why should it? | 19:44 |
| ghostmansd | recall the recent patch | 19:44 |
| ghostmansd | we discussed, that we simply merge these | 19:44 |
| ghostmansd | and create a new opcode | 19:44 |
| ghostmansd | check the mask for these entries | 19:45 |
| lkcl | .... then i need direct access to the *merged* list | 19:45 |
| ghostmansd | rldic FieldsOpcode(value=0x78000008, mask=0xfc00001f) | 19:45 |
| lkcl | where are those obtained from? | 19:45 |
| lkcl | i need the actual original list | 19:45 |
| lkcl | from which they are merged | 19:45 |
| ghostmansd | Hm. It disappears. | 19:45 |
| ghostmansd | But you can hack... | 19:45 |
| lkcl | or... do i need it... | 19:45 |
| ghostmansd | ditto def merge in power_insn | 19:46 |
| ghostmansd | and its invocation | 19:46 |
| ghostmansd | before _this_ gets called, you have set of instructions | 19:46 |
| lkcl | ... yes, i need it, because these are displaying entries. | 19:46 |
| ghostmansd | which differ by opcode but have the same name | 19:46 |
| ghostmansd | db[section].add(_functools.reduce(merge, records)) | 19:46 |
| ghostmansd | this line merges such entries | 19:47 |
| lkcl | ok i'm going to add an option to stop that | 19:47 |
| ghostmansd | it's not that simple, the upper layer expects 1 instruction IIRC | 19:48 |
| lkcl | frick | 19:48 |
| ghostmansd | not a list or set or whatever | 19:48 |
| ghostmansd | hang on | 19:48 |
| ghostmansd | OK what you can do... | 19:48 |
| ghostmansd | drop merge AND refactor PPCRecord.__getitem__ | 19:48 |
| ghostmansd | so that it yields, not returns | 19:49 |
| lkcl | i'm not going to be able to cope with that :) | 19:49 |
| ghostmansd | I can do it I think | 19:49 |
| lkcl | appreciated | 19:49 |
| ghostmansd | this is just calling merge later | 19:49 |
| ghostmansd | that is, not on PPC database layer | 19:49 |
| * lkcl need to rest. a bit hyped up at the moment | 19:51 | |
| ghostmansd | I'll do it tomorrow, OK? | 19:51 |
| ghostmansd | way too tired now | 19:51 |
| *** octavius <octavius!~octavius@240.147.93.209.dyn.plus.net> has joined #libre-soc | 19:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 19:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.64> has joined #libre-soc | 19:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.64> has quit IRC | 20:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:13 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:50 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 21:16 | |
| ghostmansd | You know what? Fuck it, I know it's a showstopper. I just did it. | 21:17 |
| ghostmansd | Just iterate over insn.ppc. | 21:17 |
| ghostmansd | Ah, by the way, it's in dis branch, I'm again a bit ahead of the rest of the sources. I'm leaving the tests to you if you're brave enough to merge it. :-) | 21:18 |
| ghostmansd | It actually was surprisingly easy. I had to introduce one smallish hack here (__getattr__), but even this one is not strictly needed, I'll drop it later. | 21:19 |
| ghostmansd | So, yeah, just treat insn.ppc as a tuple (it in fact is a tuple; it should better have been a frozen set, but who gives a fuck). If you need to know all entries, iterate over insn.ppc; if you need the PPC opcode as if it was merged... unsurprisingly simply use insn.ppc.opcode. | 21:22 |
| ghostmansd | lkcl ^ | 21:22 |
| ghostmansd | Actually I probably wouldn't do it such simply unless I started from the merge, which is a funny coincidence. | 21:22 |
| ghostmansd | -010-,SHIFT_ROT,OP_RLC,NONE,CONST_SH,RS,RA,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC_ONLY,0,0,rldic,MD, | 21:24 |
| ghostmansd | +0100,SHIFT_ROT,OP_RLC,NONE,CONST_SH,RS,RA,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC_ONLY,0,0,rldic,MD, | 21:24 |
| ghostmansd | +0101,SHIFT_ROT,OP_RLC,NONE,CONST_SH,RS,RA,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC_ONLY,0,0,rldic,MD, | 21:24 |
| ghostmansd | These leads to two records, with opcode values being 0x4 and 0x5. | 21:24 |
| *** octavius <octavius!~octavius@240.147.93.209.dyn.plus.net> has quit IRC | 21:38 | |
| lkcl | ghostmansd, thank you | 22:15 |
| * lkcl needed rest | 22:16 | |
| ghostmansd | lkcl, np | 22:21 |
| lkcl | time to run tests in dis branch and cut over, methinks | 22:24 |
| ghostmansd | let me push | 22:25 |
| lkcl | ack | 22:25 |
| ghostmansd | done | 22:25 |
| ghostmansd | I realized that I need to split stuff like D(RA) into two operands | 22:25 |
| lkcl | yyep | 22:25 |
| ghostmansd | currently they're recognized as one | 22:25 |
| lkcl | that's done in.. | 22:26 |
| lkcl | in... | 22:26 |
| lkcl | err | 22:26 |
| ghostmansd | svp64.py | 22:26 |
| ghostmansd | I know | 22:26 |
| lkcl | or it was. for ld-st-with-shift | 22:26 |
| ghostmansd | but not in the part I need | 22:26 |
| ghostmansd | not in pagereader | 22:26 |
| ghostmansd | oh well | 22:26 |
| lkcl | urr | 22:26 |
| ghostmansd | pagereader doesn't need it, actually | 22:26 |
| lkcl | it's not hard | 22:26 |
| ghostmansd | I need it :-) | 22:26 |
| lkcl | no | 22:26 |
| ghostmansd | yeah I know | 22:26 |
| ghostmansd | I'll split these at power_insn | 22:27 |
| ghostmansd | but not today, I already worked since 10 AM | 22:27 |
| lkcl | if passes all good for rebase on master? | 22:27 |
| * lkcl brainmelting | 22:27 | |
| ghostmansd | yep, feel free to rebase | 22:27 |
| lkcl | sorry, rebase of master? | 22:27 |
| lkcl | great. about 1/2 hr i imagine | 22:28 |
| ghostmansd | yeah | 22:28 |
| ghostmansd | but still quite a productive day | 22:28 |
| ghostmansd | note that I had to change the way verbose output is done | 22:28 |
| ghostmansd | now we're able to output multi-line | 22:28 |
| ghostmansd | I thought about traversing fields, and, well, some are way too long | 22:29 |
| ghostmansd | s/long/wide/ | 22:29 |
| ghostmansd | and from wide they became long :-) | 22:29 |
| ghostmansd | anyway, this is the best I could come up with, unless we want to dive into text wrapping (we don't) | 22:30 |
| ghostmansd | OK time to rest | 22:30 |
| ghostmansd | gn! | 22:30 |
| lkcl | night :) | 22:30 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 22:46 | |
| *** klys <klys!~mdasoh@show.op8.us> has quit IRC | 23:14 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 23:29 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 23:29 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 23:31 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!