| *** octavius <octavius!~octavius@244.147.93.209.dyn.plus.net> has quit IRC | 01:21 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 04:42 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:49 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 05:39 | |
| ghostmansd | addpcis is not present in our CSVs | 05:49 |
|---|---|---|
| ghostmansd | lkcl, do we support sv.fmvis, sv.fishmv? If so, how the remapping happens? | 06:37 |
| ghostmansd | Ah wait I see. D does not participate in remap. | 06:38 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:46 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:49 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.14> has joined #libre-soc | 07:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.14> has quit IRC | 08:05 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.10> has joined #libre-soc | 09:30 | |
| lkcl | correct, D is an immediate | 09:52 |
| lkcl | no immediates ever go through REMAP, only registers | 09:52 |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has joined #libre-soc | 11:38 | |
| ghostmansd[m] | Yeah I reqlized but still I decided not to inherit it from immediate (ImmediateOperand has a special meaning for stuff like D(RA)). Perhaps later I'll think how to circumcent this quirk. | 11:38 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.10> has quit IRC | 12:04 | |
| lkcl | ghostmansd, tests all good, rebased dis to master | 12:13 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:57 | |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has quit IRC | 13:10 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:43 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 13:52 | |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 13:53 | |
| ghostmansd | lkcl, I almost ready to surrender :-) | 14:00 |
| ghostmansd | This is how they do it in binutils: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-dis.c#l589 | 14:01 |
| ghostmansd | But they also seem to play tricks with ordering inside the table. | 14:02 |
| ghostmansd | OK, if I add an explicit PO matching along with mask checks, isel matches, checking others. | 14:07 |
| ghostmansd | ...but others fail. | 14:12 |
| ghostmansd | Because multiple instructions can have same XO, right, obviously. | 14:12 |
| ghostmansd | OK got another idea | 14:17 |
| lkcl | yep, it's those multi-entry switch/case statements | 14:47 |
| lkcl | https://stackoverflow.com/questions/14860967/reducing-binary-patterns-in-python | 14:48 |
| lkcl | oooooo! | 14:48 |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 14:48 | |
| lkcl | it's called the "Quine-McCluskey" algorithm :) | 14:49 |
| lkcl | oo, oo, i have to try it out | 14:49 |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 14:51 | |
| ghostmansd | OK; Opcode.value and Opcode.mask are what we get from 0s and 1s. | 14:52 |
| lkcl | ghostmansd, https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=a949c91b212e014b27ff4bd02321cb8945cf691b | 15:01 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/quine.py;hb=HEAD | 15:01 |
| lkcl | does exactly what is expected. | 15:01 |
| lkcl | reduces isel down to a single entry | 15:01 |
| lkcl | fails to reduce svshape. finds three *really* interesting patterns, but still fails to get them down to one. which is expected. | 15:02 |
| lkcl | actually, this is a really important algorithm for us to use in nmigen | 15:02 |
| lkcl | because it too ends up creating massive verbose switch/case statements | 15:03 |
| lkcl | that are in desperate need of reduction | 15:03 |
| ghostmansd | I don't understand how to adopt it to the existing code. I can make Opcode class produce such bitvector, but what next? | 15:05 |
| lkcl | if the resultant list is only one long, the result is both the value and the mask | 15:08 |
| lkcl | actually... | 15:09 |
| lkcl | simpler than that | 15:09 |
| lkcl | PatternOpcode(result[1]) | 15:09 |
| lkcl | that's it | 15:09 |
| lkcl | opcode class to produce a *list* of bitvectors | 15:10 |
| ghostmansd | This matches multiple instructions | 15:20 |
| ghostmansd | And this matches the current behaviour. | 15:20 |
| lkcl | yes. except it's automatic. | 15:21 |
| lkcl | it doesn't need "special explicit hard-coded PO matching along with mask checks, isel matches" | 15:22 |
| ghostmansd | What do you mean by automatic? There's an algorithm involved. | 15:22 |
| lkcl | it automatically and inherently identifies *all* reduction opportunities | 15:22 |
| lkcl | you do not need code: | 15:22 |
| ghostmansd | My question is, how to match? | 15:22 |
| lkcl | * if insn.name == "isel" ... | 15:22 |
| ghostmansd | There's no such code. | 15:22 |
| ghostmansd | And won't be ever. | 15:23 |
| lkcl | oh goodie :) | 15:23 |
| lkcl | PPCMultiRecord | 15:23 |
| ghostmansd | We already discussed that, I'm trying to approach it in general. | 15:23 |
| lkcl | if isinstance(PPCMultiRecord): | 15:23 |
| lkcl | get_pattern_list(...) | 15:23 |
| lkcl | new_patterns = quine.compress() | 15:24 |
| ghostmansd | The issue is that, multiple instructions are matched when I try to apply if ((value & mask) == (opcode & mask)). | 15:24 |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has joined #libre-soc | 15:24 | |
| ghostmansd | And I don't understand how replacing value:mask pair with a bitvector is going to help. | 15:24 |
| lkcl | you'll need to do exactly the same thing that i already did in the decoder/power_table.py | 15:24 |
| ghostmansd | Because this is the same to me. | 15:24 |
| lkcl | *BEFORE* you create the Fields-things-with-a-list | 15:24 |
| lkcl | remember i explained how i needed *only* the *direct* CSV file information? | 15:25 |
| lkcl | if isinstance(PPCMultiRecord) | 15:25 |
| lkcl | reduce to one | 15:25 |
| lkcl | replace PPCMultiRecord | 15:25 |
| lkcl | i think you'll find you need to call the quine.compress() function *before* you do the trick which creates that list | 15:28 |
| lkcl | (including the 6-bit PO) | 15:28 |
| lkcl | you remember? | 15:28 |
| lkcl | something about adding bits 0-5 to a list | 15:28 |
| lkcl | then adding the CSV entry | 15:28 |
| lkcl | then something else | 15:29 |
| lkcl | and finally passing that *list* over to a function that turns it into a value&mask / opcode&mask thing | 15:29 |
| lkcl | like the decoder/power_table.py | 15:29 |
| lkcl | you MUST | 15:29 |
| lkcl | call quine.compress() | 15:29 |
| lkcl | on the RAW | 15:29 |
| lkcl | CSV data | 15:29 |
| lkcl | NOT | 15:29 |
| lkcl | after the creation of the 0xNNNN_NNNN mask and 0xNNNN_NNNN value | 15:30 |
| ghostmansd | Thanks! I'll think about how to do it. | 15:31 |
| ghostmansd | Still don't understand why we need it, binutils don't. | 15:32 |
| lkcl | because you ran into a matching problem | 15:32 |
| lkcl | and because binutils is entirely hand-crafted | 15:32 |
| lkcl | they can do hand-crafted tricks as workarounds for matching problem(s) | 15:33 |
| ghostmansd | You won't believe but I did it! | 15:52 |
| ghostmansd | But w/o Quine algorithm yet | 15:53 |
| ghostmansd | I need more tricky cases. I managed to match isel and svshape and svshape2. | 15:54 |
| ghostmansd | There were errors in the algorithm. First, we never really correctly handled integer patterns, they always led to wrong mask. Second, major.csv and extra.csv with opcode=0 needed a special treat. | 16:06 |
| lkcl | w00t! | 16:07 |
| lkcl | ah yes major/extra special-case sounds familiar | 16:07 |
| lkcl | rldic* _were_ some that existed, but no more | 16:08 |
| lkcl | svshape2 is the worse offender | 16:08 |
| ghostmansd | Ah heck wait, just realized the worse offender is still here. Checking this. :-) | 16:11 |
| lkcl | :) | 16:11 |
| ghostmansd | Damn :-) | 16:12 |
| ghostmansd | Yeah I know how to deal with it. We must check XO along with the other static operands. | 16:22 |
| ghostmansd | The thing is, we don't have XO field... :-) | 16:22 |
| ghostmansd | But it's simple to support. Basically what we have in opcode already has XO, just not in explicit form. | 16:23 |
| lkcl | hence why i suggested at the CSV-file level because there is no conflict there | 16:45 |
| lkcl | (not with other CSV files) | 16:45 |
| ghostmansd | lkcl, I checked the quine.py script, and still cannot get how the match is performed. | 18:20 |
| ghostmansd | Should I match with each pattern in list? | 18:21 |
| ghostmansd | svshape ['0----011001', '1-1--011001', '110--011001'] | 18:21 |
| ghostmansd | svshape2 ['100--011001'] | 18:21 |
| ghostmansd | I think I begin to understand... | 18:34 |
| ghostmansd | I think I can do somewhat simpler: this multirecord should have entries obtained via this algorithm. | 18:35 |
| lkcl | the multirecord contains the patterns that must be handed *to* the quine algorithm | 18:37 |
| lkcl | try it with the isel patterns (you can see i extracted them from the isel CSV) | 18:37 |
| ghostmansd | https://pastebin.com/itBU1wq8 | 18:38 |
| ghostmansd | Already | 18:38 |
| ghostmansd | svshape has 28 matches, svshape2 has 4 matches, but none are common | 18:38 |
| ghostmansd | Funny | 18:43 |
| ghostmansd | This is actually the same as iterating over records WITHOUT merge | 18:44 |
| ghostmansd | This code is superior wrt compactness | 18:44 |
| ghostmansd | But otherwise it's the same | 18:44 |
| ghostmansd | With the exception that the current algorithm also takes Rc and Oe into account (but that one can also be adopted upon pattern build). | 18:49 |
| ghostmansd | lkcl, pushed | 19:18 |
| ghostmansd | OK now back to CRs | 19:21 |
| ghostmansd | lkcl, about CRs. I saw in spec and you told that there are 5-bit and 3-bit, I also recall it from pysvp64asm. But I cannot find the code in src/openpower/decoder/power_svp64_extra.py which takes care of it. | 19:36 |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has quit IRC | 19:53 | |
| ghostmansd | lkcl, note aside: I think at some point we'd like to have script called insndb, which takes opcodes or names as arguments | 20:18 |
| ghostmansd | Also I noticed that "database" takes about 1 second to load; this is a huge time, and we should strive to make it less. But not now. | 20:19 |
| ghostmansd | Oh by the way I know one trick to lookup opcodes faster. Stay tuned. | 20:20 |
| ghostmansd | OK done, plus another minor optimization. | 20:40 |
| ghostmansd | Enough for today, completely exhausted, but I hope at least this works. | 20:40 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:44 | |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has joined #libre-soc | 20:57 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:15 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:17 | |
| lkcl | ghostmansd[m], yes, i need to enumerate insndb in the decoder/power_table.py | 21:43 |
| lkcl | yes i was already asleep for a couple of hours :) | 21:43 |
| ghostmansd[m] | What do youean by enumerate? | 21:43 |
| ghostmansd[m] | for (idx, record) in db? | 21:43 |
| ghostmansd[m] | *enumerate(db) | 21:44 |
| lkcl | or at least get at the start/end point | 21:44 |
| lkcl | and separate everything out - i do a full walk to split by insn.section.path.name | 21:44 |
| ghostmansd[m] | insn.ppc has all PPC records (those from minor_XX.csv, major.csv, extra.csv, etc.) | 21:45 |
| lkcl | ahh | 21:45 |
| ghostmansd[m] | insn.svp64 has stuff from LDSTRM tables | 21:45 |
| ghostmansd[m] | insn.mdwn has stuff from mdwn files (not all, currently only pcode and operands) | 21:46 |
| lkcl | yep i have partly forgotten how power_table.py works already :) | 21:46 |
| ghostmansd[m] | Ah OK | 21:46 |
| ghostmansd[m] | Please check about CRs when you have the time | 21:47 |
| ghostmansd[m] | Copying here for convenience | 21:47 |
| ghostmansd[m] | lkcl, about CRs. I saw in spec and you told that there are 5-bit and 3-bit, I also recall it from pysvp64asm. But I cannot find the code in src/openpower/decoder/power_svp64_extra.py which takes care of it. | 21:47 |
| ghostmansd[m] | This is stuff I'm going to do tomorrow. | 21:47 |
| lkcl | i cheated, remember? | 21:47 |
| lkcl | because they are identical except for the bottom 2 LSBs | 21:48 |
| lkcl | for 5-bit i chopped off the 2 LSBs | 21:48 |
| lkcl | ran through the same SVP64CRExtra class | 21:48 |
| lkcl | then put the 2 LSBs back on afterwards | 21:48 |
| ghostmansd[m] | Yes, this is the part I want to check | 21:49 |
| ghostmansd[m] | Where are these chopped? | 21:49 |
| lkcl | bottom 2 LSBs. | 21:49 |
| ghostmansd[m] | Ah so you simply take 0, 1, 2? | 21:49 |
| lkcl | yyep | 21:50 |
| ghostmansd[m] | Ok gotcha | 21:50 |
| lkcl | in MSB0 numbering | 21:50 |
| lkcl | you should even be able to have the same function process both | 21:50 |
| lkcl | by spotting "if len(x) == 5" CHOP | 21:50 |
| ghostmansd[m] | Ok I'll check | 21:52 |
| ghostmansd[m] | Anyway this _should_ take less than GPR/FPR... Can I hope at least for this? :-D | 21:53 |
| lkcl | it should do because it's practically the same | 21:54 |
| lkcl | except the shift amounts. | 21:54 |
| lkcl | compare SVP64CRExtra and GPRExtra, really those amounts should be parameterised with common code | 21:54 |
| lkcl | # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2] | 21:55 |
| lkcl | # Vector: shifted up, extra in LSBs (CR << 4) | (spec[1:2] << 2) | 21:55 |
| lkcl | # Scalar: not shifted up, extra in MSBs RA | (spec[1:2] << 5) | 21:55 |
| lkcl | # Scalar: not shifted up, extra in MSBs CR | (spec[1:2] << 3) | 21:55 |
| lkcl | i mean, duh, how hard is that? :) | 21:55 |
| ghostmansd[m] | Duh, how hard is matching the opcode? :-) | 21:57 |
| ghostmansd[m] | But OK | 21:57 |
| lkcl | haha | 22:00 |
| *** octavius <octavius!~octavius@150.209.147.147.dyn.plus.net> has quit IRC | 22:46 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!