| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:03 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 03:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 06:02 | |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 06:02 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 06:02 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 06:02 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC | 06:02 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 06:02 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 06:02 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC | 06:02 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 06:02 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 06:02 | |
| *** hl <hl!~hl@user/hl> has quit IRC | 06:02 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has quit IRC | 06:02 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has quit IRC | 06:02 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 06:03 | |
| *** yambo <yambo!~yambo@184.166.146.205> has joined #libre-soc | 06:03 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 06:03 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 06:03 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc | 06:03 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 06:03 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 06:03 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc | 06:03 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 06:03 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 06:03 | |
| *** hl <hl!~hl@user/hl> has joined #libre-soc | 06:03 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has joined #libre-soc | 06:03 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has joined #libre-soc | 06:03 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:06 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:06 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 06:06 | |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 06:06 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 06:06 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 06:06 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC | 06:06 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 06:06 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 06:06 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC | 06:06 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 06:06 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 06:06 | |
| *** hl <hl!~hl@user/hl> has quit IRC | 06:06 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has quit IRC | 06:06 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has quit IRC | 06:06 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 06:06 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 06:06 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 06:06 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 06:06 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 06:06 | |
| *** ckie <ckie!~ckie@user/cookie> has quit IRC | 06:06 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 06:06 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 06:06 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC | 06:06 | |
| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 06:06 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:06 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has joined #libre-soc | 06:06 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has joined #libre-soc | 06:06 | |
| *** hl <hl!~hl@user/hl> has joined #libre-soc | 06:06 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 06:06 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 06:06 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc | 06:06 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 06:06 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 06:06 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc | 06:06 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 06:06 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 06:06 | |
| *** yambo <yambo!~yambo@184.166.146.205> has joined #libre-soc | 06:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 06:07 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc | 06:07 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 06:07 | |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 06:07 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 06:07 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 06:07 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 06:07 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 06:07 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 06:07 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 06:07 | |
| *** ckie <ckie!~ckie@user/cookie> has joined #libre-soc | 06:07 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:07 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:07 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 06:07 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 06:07 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 06:07 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 06:08 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 06:08 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 06:08 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 06:08 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 06:10 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC | 06:10 | |
| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 06:10 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 06:10 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc | 06:10 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 06:10 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 06:10 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 06:13 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 06:13 | |
| *** ckie <ckie!~ckie@user/cookie> has quit IRC | 06:13 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 06:13 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 06:14 | |
| *** ckie <ckie!~ckie@user/cookie> has joined #libre-soc | 06:14 | |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 06:14 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 06:14 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 06:14 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 06:15 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 06:19 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 06:34 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 06:42 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 06:42 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 06:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:31 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 08:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:31 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 09:00 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:08 | |
| ghostmansd | lkcl, I've restored target_addr. I checked test_caller.py and test_caller_svp64.py, and also checked some stuff manually with debug prints (e.g. that the name of the operand is OK as it goes to power_insn layer). | 10:11 |
|---|---|---|
| ghostmansd | Let me know if any problems come up. | 10:11 |
| ghostmansd | Meanwhile I'll support stuff like D(RA). | 10:11 |
| ghostmansd | OK done | 10:27 |
| ghostmansd | There's however one quirk which must be updated, too | 10:28 |
| ghostmansd | Hm. Perhaps I'll refactor it. | 10:28 |
| lkcl | excellent | 10:47 |
| lkcl | programmerjake, nicely gone on reallocation of ffmadds etc. you saw ghostmansd and i sorted out creating a mdwn table from the csv files? | 10:49 |
| lkcl | it's reaall basic at the moment | 10:49 |
| lkcl | but functional | 10:49 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 10:49 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:50 | |
| lkcl | ghostmansd, one thing that is "Bad(tm)" though is: a not-infrequent number of times the "conflict" alert gets raised | 10:51 |
| lkcl | but it's random (!) | 10:51 |
| lkcl | File "decoder/power_table.py", line 83, in do_table | 10:51 |
| lkcl | insn.name) | 10:51 |
| lkcl | AssertionError: entry 0 1 should be empty contains rldic conflicting rldicl | 10:51 |
| lkcl | 2nd run: | 10:51 |
| programmerjake | ah, actually I'm working the other way around rn...allocating opcodes in a markdown table on the wiki, and am writing a quick script to sync the rest of the mdwn file from the PO=59 table | 10:52 |
| lkcl | programmerjake, that's already been done. | 10:52 |
| ghostmansd | lkcl, I don't quite get what you mean by conflict | 10:52 |
| lkcl | please don't duplicate work | 10:52 |
| ghostmansd | could you, please, share a bit more in details? | 10:53 |
| lkcl | and please discuss these things with me. | 10:53 |
| programmerjake | lkcl: how so? I'm not aware of any code that takes stuff from columns like: | 10:53 |
| programmerjake | | 10000 | <small>`10000 01100`</small><br/>(ffadds) (draft) | <small>`10000 01101`</small><br/>fsinpis (draft) | <small>`10000 01110`</small><br/>fatan2pis (draft) | <small>`10000 01111`</small><br/>fasinpis (draft) | | 10:53 |
| ghostmansd | I have literally no idea what lower and upper mean | 10:53 |
| ghostmansd | and what "table_entries" stand for | 10:53 |
| lkcl | the lower half of the XO and the upper half of the XO | 10:54 |
| programmerjake | and puts the XO codes in | fatan2pi(s)| atan2 arc tangent / π | 10000 01110 | | 10:54 |
| lkcl | programmerjake, ok that would work well | 10:54 |
| lkcl | ghostmansd, so the table_entries is a 2D dictionary of rows-columns which gets print()ed as a markdown table | 10:54 |
| programmerjake | so, to clarify, I'm not duplicating work rn? | 10:55 |
| lkcl | programmerjake, well, kind-of | 10:55 |
| lkcl | we literally just did CSV-reading last night, or, using ghostmansd's PowerISA database-reader | 10:56 |
| programmerjake | iirc the code you're writing goes from .csv files to markdown tables... | 10:56 |
| lkcl | yes. | 10:56 |
| programmerjake | my code goes from markdown tables to markdown tables | 10:56 |
| lkcl | it would be better to rip out the markdown tables entirely and autogenerate them | 10:56 |
| lkcl | then drop them into an underlay as an automated command | 10:57 |
| programmerjake | maybe, but I like editing markdown tables best when I'm deciding what goes where... | 10:57 |
| lkcl | 10:57 | |
| lkcl | yeah that sounds reasonable, i do as well | 10:57 |
| programmerjake | a simple regex can convert the results to the csv format | 10:57 |
| programmerjake | that's what I did when I found the overlap | 10:58 |
| programmerjake | regex, then sort lines | 10:58 |
| lkcl | programmerjake, power_table.py is intended to re-create the Appendix tables so that we're certain there's no overlaps across multiple instructions being designed/added | 10:59 |
| lkcl | like | 10:59 |
| lkcl | (sigh) | 10:59 |
| lkcl | ffmadds | 10:59 |
| lkcl | which i totally forgot to check | 10:59 |
| programmerjake | I moved ffmadds... | 10:59 |
| lkcl | ghostmansd, so what power_tables.py does is literally walk through every single binary number 0b00000000 to 0b11111111 | 10:59 |
| lkcl | and create a lower-half mask and an upper-half mask | 10:59 |
| lkcl | programmerjake, yes i saw. good call on X-Form. | 11:00 |
| programmerjake | uuh, I'm assuming you want 10-bit numbers there, not 8-bit | 11:00 |
| lkcl | the lower-half is the row-number, the upper-half is the column number (something like that) | 11:00 |
| lkcl | programmerjake, it's read from insndb.csv | 11:00 |
| programmerjake | ah, k | 11:00 |
| lkcl | so minor_30 is 4-bit (picked because it's smaller) | 11:00 |
| lkcl | i tried minor_22 holy cow the table was massive. 11-bit | 11:01 |
| ghostmansd | OK I'm done with immediate operands | 11:08 |
| ghostmansd | They end up with a standalone entry in operands, but now print correctly in the whole spec | 11:09 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=919#c8 example | 11:10 |
| ghostmansd | OK, now on to power_table.py | 11:10 |
| lkcl | fantastic | 11:10 |
| ghostmansd | All discussion here is somewhat mixed with comments on several topics :-) | 11:10 |
| ghostmansd | Again, what's the issue and what exactly do you check with this assertion? | 11:11 |
| lkcl | is there a conflict, yes no. | 11:11 |
| lkcl | conflict: two instructions attempt to go in same XO | 11:11 |
| lkcl | run python3 decoder/power_table.py ten times | 11:12 |
| lkcl | you should find that appx 4/6 times, an assert is called. clearly that's catastrophic. | 11:13 |
| lkcl | ah i just noticed | 11:13 |
| ghostmansd | Likely it depends on the order of entries. | 11:14 |
| lkcl | when it occurs, it's actually the case that the two PatternOpcodes are in fact the same | 11:14 |
| lkcl | op rldic PatternOpcode(value=0x00000004, mask=0x0000000e) | 11:14 |
| lkcl | op rldicl PatternOpcode(value=0x00000004, mask=0x0000000e) | 11:14 |
| lkcl | AssertionError: entry 0 1 (XO 0b100) should be empty contains rldic conflicting rldicl | 11:14 |
| ghostmansd | This shouldn't happen, they should've ended with different patterns. | 11:15 |
| ghostmansd | OK, I'm checking this. | 11:15 |
| lkcl | oh i worked out how to use PPCMultiRecord, it was dead simple. not obvious (inheriting from tuple) but simple to use | 11:16 |
| ghostmansd | well this was the simplest option | 11:16 |
| lkcl | yes, works well | 11:17 |
| lkcl | programmerjake, no instruction may be unique in the 64-bit space. | 11:20 |
| ghostmansd | This code https://pastebin.com/9K2Mh82M | 11:20 |
| ghostmansd | prints this https://pastebin.com/6aY8HUTJ | 11:21 |
| lkcl | now run it 10 times | 11:21 |
| ghostmansd | Aaaah I see | 11:21 |
| ghostmansd | The pattern changes | 11:21 |
| lkcl | yyep | 11:21 |
| ghostmansd | Likely it's caused by the way the merge is implemented and depends on the particular order | 11:22 |
| ghostmansd | Yes it's caused by the set mutable order | 11:28 |
| lkcl | okaaay | 11:28 |
| lkcl | good thing that was found :) | 11:28 |
| ghostmansd | But also the merge is likely broken, it should've given same result regardless of the order | 11:28 |
| ghostmansd | Could you, please, take a look at it? | 11:28 |
| ghostmansd | I'm not sure how to approach it better. | 11:29 |
| lkcl | cando. | 11:29 |
| ghostmansd | What it does is it calls reduce on iterable of PPCRecord... | 11:29 |
| ghostmansd | ...upon each iteration it receives a pair of records, the one from the previous step (or the first one if it's the first call), and the next one in the iterable. | 11:30 |
| ghostmansd | Then it tries to produce a new PPCRecord with the replaced opcode. | 11:30 |
| lkcl | ahhh it has to be done in one hit, not as a merge | 11:32 |
| ghostmansd | What do you mean, in one hit? | 11:33 |
| ghostmansd | There're multiple records, we have to iterate anyway. | 11:33 |
| lkcl | not using reduce. | 11:34 |
| lkcl | the entire batch has to be analysed in one go. | 11:34 |
| lkcl | reduce will do merge(1,merge(2,merge(3,merge(4,merge(5,6))))) | 11:34 |
| ghostmansd | Yes | 11:35 |
| lkcl | what's needed is: | 11:35 |
| lkcl | global initial value=0 | 11:35 |
| lkcl | global initial mask = 0 | 11:35 |
| lkcl | for insn in list_of_opcodes: | 11:35 |
| lkcl | for each bit | 11:35 |
| lkcl | .... | 11:35 |
| lkcl | the ordering of those merge()s could end up | 11:36 |
| lkcl | merge(5,merge(3,merge(1,merge(6,merge(2,4)))))) | 11:36 |
| lkcl | and the intermediary results end up completely wrong (i don't entirely know how) | 11:37 |
| ghostmansd | Yeah, but we simply check if the bits differ on the previous stage, don't we? | 11:37 |
| ghostmansd | *from the previous stage | 11:37 |
| ghostmansd | OK, let's simplify the task | 11:37 |
| lkcl | wait... hang on... we're talking masks here. single-entry masks | 11:37 |
| ghostmansd | Assuming we have only two opcodes. | 11:37 |
| lkcl | reduce on a single-entry shouldn't even *activate* this code | 11:38 |
| lkcl | reduce([anything]) should always return [anything] | 11:38 |
| lkcl | oink | 11:38 |
| lkcl | programmerjake, ffmadds etc. all have implicit RS regs because they're 3-in 2-out | 11:40 |
| lkcl | you just have to be "aware" of that. there's nothing that can be done about it - no "safety" net | 11:40 |
| programmerjake | I knew that, did I mess something up? | 11:41 |
| lkcl | no. | 11:41 |
| programmerjake | k, good | 11:42 |
| lkcl | it's the bugreport comment "fix the hack" that i found a little irritating | 11:42 |
| lkcl | because it's good enough for now and needs considerable work to create mini-power-decoders | 11:43 |
| programmerjake | oh, imho it's supposed to be somewhat irritating so it gets fixed eventually, imho adding an extra field to the csv "is svp64 fft op" and changing that switch I added to iterate through the csv should be good enough | 11:44 |
| lkcl | it should be more likely called "3in2out" or something as that's what it's for | 11:45 |
| lkcl | there will be more like that | 11:45 |
| programmerjake | i didn't look super closely at the code using the svp64 fft variable, I just figured out I had to change it because the tests failed | 11:46 |
| programmerjake | to make it consistent with the state before I moved the instructions | 11:46 |
| lkcl | grr, i hate adding extra csv columns, it hits every single file. | 11:47 |
| programmerjake | no it doesn't, you can have the csv column have a default value so you only need to add it to files where it doesn't always have that default value | 11:47 |
| programmerjake | like my_dict.get("key", my_default) | 11:48 |
| programmerjake | iirc there are several columns that already do that | 11:48 |
| programmerjake | rather than "3in2out" i'd name it "implicit RS out" or similar | 11:49 |
| programmerjake | name it for what it does, rather than what properties usually enable it | 11:50 |
| programmerjake | since I'd expect there might eventually be ops with implicit RS out that aren't 3-in 2-out | 11:50 |
| lkcl | there's EA from ld-st-with-update. | 11:52 |
| lkcl | # update mode LD/ST uses read-reg A also as an output | 11:53 |
| lkcl | with m.If(op.upd == LDSTMode.update): | 11:53 |
| lkcl | comb += self.reg_out.data.eq(self.dec.RA) | 11:53 |
| lkcl | blech | 11:53 |
| programmerjake | imho ldu is different than implicit RS out ops, since it usually writes back to the same register, rather than writing to a different register | 11:53 |
| programmerjake | ldu is more like the rotate immediate something-or-other op that reads RT and writes RT | 11:54 |
| lkcl | yyep just looking at DecodeOut2 it's using a bit fp_madd_en to decode whether to offset RS by VL | 11:55 |
| lkcl | err that should be maxvl, damn | 11:55 |
| lkcl | whoaaaa 70 simulator test failures | 11:56 |
| lkcl | entries = filter(lambda entry: "TODO" \ | 11:57 |
| lkcl | > not in frozenset(entry.values()), entries) | 11:57 |
| lkcl | E TypeError: unhashable type: 'list' | 11:57 |
| lkcl | ../power_insn.py:1259: TypeError | 11:57 |
| lkcl | ../../test/algorithms/svp64_utf_8_validation.py:309: in program | 11:57 |
| lkcl | return assemble(svp64_utf8_validation_asm()) | 11:57 |
| lkcl | that sounds/seems like an honest double-commit conflict | 11:58 |
| programmerjake | idk what caused that, but it passed CI when I committed | 11:58 |
| lkcl | what git commit are you on? | 11:59 |
| programmerjake | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3183292 | 11:59 |
| ghostmansd | Could it be me? | 11:59 |
| ghostmansd | power_insn | 11:59 |
| lkcl | i'm not interested in the job number, i need to know what commit you are currently on - what the master branch is | 12:00 |
| lkcl | ghostmansd, possibly, with the immediate operands refactoring | 12:00 |
| programmerjake | you can see what commit it is by looking at that url | 12:00 |
| ghostmansd | hm, doesn't look like it's the actual version: line 1259 doesn't seem right | 12:00 |
| lkcl | fer f's sake. | 12:01 |
| programmerjake | the last passed commit in CI is 04dad392 (not what I linked to) | 12:01 |
| lkcl | those URLs overload my machine(s) | 12:01 |
| lkcl | ok great. that leaves two possible commits | 12:01 |
| programmerjake | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs (won't overload your phone) | 12:01 |
| ghostmansd | line 1259 of power_insn.py is `class MarkdownDatabase:` | 12:02 |
| ghostmansd | ah wait | 12:02 |
| ghostmansd | there's more commits, I needed to pull | 12:02 |
| ghostmansd | Fuck | 12:02 |
| programmerjake | I'm working on libreriscv.git, so that's probably my last commit to openpower-isa.git tonight... | 12:03 |
| ghostmansd | Luke, was this whitespace cleanup completely necessary now? | 12:03 |
| lkcl | programmerjake, ok | 12:03 |
| ghostmansd | OK something gone wrong with CSVs it seems | 12:03 |
| ghostmansd | what to run to reproduce? | 12:04 |
| programmerjake | did you forget to run `make`? | 12:04 |
| lkcl | ohhh hang on - sv_analysis might need running | 12:05 |
| programmerjake | I changed opcodes, it needs to be run | 12:05 |
| lkcl | it updates the svp64 CSV files so should *always* be done and committed at the time that the 32-bit CSV files are altered | 12:06 |
| ghostmansd | entries = filter(lambda entry: "TODO" \ | 12:06 |
| ghostmansd | not in frozenset(entry.values()), entries) | 12:06 |
| programmerjake | imho just get in the habit of running make after git pull --ff-only -- it only takes like 15s | 12:06 |
| lkcl | bit it's ok - no change needed | 12:06 |
| ghostmansd | Seriously, such whitespace cleanup hurts even more than lack of it. | 12:06 |
| lkcl | because, ha, the rest of the columns didn't change | 12:06 |
| lkcl | ghostmansd, then it should be done on 2 lines rather than one | 12:06 |
| ghostmansd | Then do it properly, not in an automatic way which breaks in completely unconvenient place | 12:07 |
| lkcl | gimme 1 sec | 12:07 |
| ghostmansd | I'll do it | 12:07 |
| lkcl | ok | 12:07 |
| ghostmansd | Throughout the whole code I inserted indentation manually | 12:08 |
| ghostmansd | For God's sake, simply indent by level | 12:08 |
| ghostmansd | Not by some goddamn = sign | 12:08 |
| ghostmansd | Or "TODO" keyword | 12:08 |
| ghostmansd | Pfff, let me chill and simply strange at the code | 12:09 |
| lkcl | :) | 12:09 |
| * lkcl running test_caller_svp64_utf_8_validation.py on commit 04dad39 | 12:11 | |
| lkcl | f1865fb853 is next, then f4a7f0a7d71 after that. | 12:11 |
| lkcl | takes a long time, could do with some kind of reporting to be able to cut out some of the cases | 12:12 |
| programmerjake | lkcl: try testing src/openpower/decoder/isa/test_caller_svp64_alu.py, it fails with TypeError during setup on c0484ef6 | 12:15 |
| programmerjake | should be much faster | 12:15 |
| lkcl | programmerjake, yes just found that one | 12:15 |
| lkcl | a lot frickin faster | 12:17 |
| programmerjake | yeah, cuz utf-8 validation runs like 1500 test cases of a whole function | 12:17 |
| lkcl | faaakin'ellfire :) | 12:17 |
| lkcl | that's going on the "slow" list :) | 12:18 |
| programmerjake | hence why I added code to split it up into 64 (? icr) subtests so they can be run in parallel | 12:18 |
| programmerjake | ok, not self.subTest, but separate test entry functions that run part of the test case list | 12:19 |
| lkcl | parallelism is of absolutely no use here when running on a machine where the loadavg goes up to 25 if doing so and becomes unresponsibe | 12:19 |
| lkcl | you *can't* assume that everyone's machines are the same | 12:19 |
| programmerjake | parallelism is entirely controlled by the argument you pass to pytest...if you run pytest -n 3 it'll run 3 tests at most at a time | 12:20 |
| programmerjake | so if your machine goes to loadaverage 25, then pick a smaller number than pytest -n 25 | 12:21 |
| lkcl | i'm not using pytest for individual runs | 12:21 |
| lkcl | please just don't make assumptions that tests *must* be run in parallel | 12:21 |
| lkcl | at all | 12:21 |
| lkcl | ok? | 12:21 |
| programmerjake | if you use unittest, it doesn't run anything in parallel. if you run nose, it has a similar option to pytest | 12:22 |
| lkcl | we need a range of *fast* tests as well as comprehensive ones, ok? | 12:22 |
| lkcl | i run the test directly as a command. | 12:22 |
| lkcl | i don't expect it to take 15 minutes to complete because of assumptions "it must be run in parallel" | 12:22 |
| programmerjake | running it directly gets you unittest, which should be singlethreaded | 12:22 |
| lkcl | exactly | 12:22 |
| lkcl | so it would be better to have 20 separate .py files than it would to make the assumption that one file *must* run massive parallelism | 12:23 |
| programmerjake | it isn't "it must be run in parallel", it's "it needs to test all the corner cases, parallelism is useful for not taking 30m" | 12:23 |
| lkcl | that way it's possible to run just the one file | 12:23 |
| lkcl | oink. | 12:23 |
| lkcl | there's nothing wrong, now. | 12:24 |
| lkcl | wtf. | 12:24 |
| ghostmansd | OK I pushed the whitespace cleanup | 12:24 |
| lkcl | i ran the individual test - on master - and it's passing | 12:24 |
| lkcl | oink | 12:24 |
| programmerjake | if you want to just run 1 subtest, just run test_....py TestSVP64UTF8Validation0 | 12:24 |
| ghostmansd | Next time, please, don't do it that way you did. | 12:24 |
| lkcl | how am i supposed to know that? | 12:24 |
| lkcl | ghostmansd, ack | 12:24 |
| ghostmansd | And, if you're really bothered, let's setup a hook, for God's sake | 12:25 |
| ghostmansd | I've been developing it for too many days already, I cannot keep an attention for each and every single line. | 12:25 |
| ghostmansd | So, we might establish a hook which prevents this to be pushed. | 12:25 |
| lkcl | unfortunately there's places where off-the-internet URLs overrun and there's nothing that can be done about that | 12:26 |
| programmerjake | lkcl: because it's standard unittest interface, so you can always pass a subtest filter list | 12:26 |
| lkcl | (not without breaking up the URL, which is worse) | 12:26 |
| ghostmansd | OK back to opcodes merge. | 12:26 |
| lkcl | ok so we've a situation where pytest fails but the same individual unit test does not | 12:26 |
| lkcl | ahhh i'm going to re-run the test multiple times | 12:27 |
| programmerjake | is it a case of subtly depending on soc again? | 12:27 |
| programmerjake | or maybe it doesn't like running in parallel because someone assumed only 1 process would run at a time? | 12:27 |
| programmerjake | standard practice for me and for CI is to assume process-level parallelism | 12:28 |
| lkcl | no, sigh, it's a case of me being dumb and running the wrong damn test :) | 12:28 |
| lkcl | test_caller_alu.py | 12:28 |
| lkcl | not test_caller_svp64_alu.py | 12:28 |
| * lkcl face-palm | 12:29 | |
| programmerjake | welp | 12:29 |
| lkcl | okaaaay. repro | 12:29 |
| programmerjake | I'd just type ctrl+R to get the last time I ran a test... | 12:29 |
| programmerjake | assuming your repeating the same test | 12:29 |
| lkcl | commit 611e5 good | 12:30 |
| lkcl | programmerjake, i typed it out manually the 1st time | 12:30 |
| lkcl | commit f43c616a good | 12:30 |
| ghostmansd | OK I have a minimal reproducer for opcodes issue and can debug it now | 12:31 |
| lkcl | ghostmansd, fantastic | 12:31 |
| lkcl | ahh utterly stupid of me. | 12:34 |
| lkcl | in the comment on the csv file i added a comma | 12:35 |
| * lkcl facepalm | 12:35 | |
| programmerjake | uuh, don't you strip comments before parsing csv? | 12:35 |
| programmerjake | also commas were there when I tested and it worked... | 12:36 |
| lkcl | field,field,comment-with-a-comma-in-it | 12:36 |
| lkcl | is interpreted as | 12:36 |
| lkcl | field,field,commment-first-half,comment-second-half | 12:36 |
| programmerjake | oh...you mean the comment field, not a # my goofy comment!! | 12:36 |
| programmerjake | all you need is " | 12:37 |
| lkcl | sigh | 12:37 |
| lkcl | btw folks i spoke to michiel and he's ok with reallocating the budget of #241. | 12:40 |
| lkcl | #254 sorry | 12:40 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=254 | 12:40 |
| lkcl | which is a continuation task anyway but with a primary focus on 3D | 12:40 |
| programmerjake | yeah, we're nowhere close enough to do that...sadly | 12:41 |
| lkcl | which is why i asked if it could be reallocated, and he said yes | 12:42 |
| ghostmansd | Fuck | 13:04 |
| ghostmansd | I think I know | 13:04 |
| ghostmansd | It's the name matching algorithm | 13:05 |
| ghostmansd | It sees "l" in the end for stuff like rldicl | 13:06 |
| ghostmansd | And, well, it matches rldic or rldicl | 13:06 |
| ghostmansd | Sometimes one, sometimes another | 13:07 |
| ghostmansd | OK, we must first check for the exact match, and only then try the loosy ones | 13:08 |
| ghostmansd | lkcl, please try again | 13:12 |
| ghostmansd | At least this shouldn't heisenbug us anymore | 13:13 |
| ghostmansd | By the way, all suggestions on how to improve and/or fix the matching are more than welcome. | 13:14 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=3a3a662565a157cfb6a03b0ee5bda878e9f145ed;hb=cac416fd956a7349250bc624faf5a7c4ce5c07a8#l1342 | 13:15 |
| ghostmansd | lkcl, beware: I'm going to change PPCDatabase constructor so that it no longer takes redundant parameter (a leftover from some debug session). | 13:21 |
| ghostmansd | You know what? Nevermind, I'll simply update power_table for you. | 13:22 |
| ghostmansd | db = Database(root) | 13:28 |
| ghostmansd | for insn in db: | 13:28 |
| ghostmansd | insns[str(insn.section.path)].append(insn) | 13:28 |
| ghostmansd | print (insn) | 13:28 |
| ghostmansd | I'll also simplify the code | 13:28 |
| ghostmansd | lkcl, done, also replaced all prints with log (except for the table itself) | 13:34 |
| ghostmansd | ping me if you need help rebasing | 13:35 |
| ghostmansd | https://pastebin.com/vw5BgQvm | 13:35 |
| ghostmansd | ^ what we have when we run power_table script with SILENCELOG=true | 13:36 |
| ghostmansd | OK let the Dobby proceed with SVP64 disassembly now | 13:37 |
| lkcl | ghostmansd, ahh that'll do it :) | 13:46 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/power_insn.py", line 1429, in __init__ | 13:47 |
| lkcl | ppcdb = PPCDatabase(root=root, mdwndb=mdwndb, fieldsdb=fieldsdb) | 13:47 |
| lkcl | moo? | 13:47 |
| lkcl | ok. i take it you're in the middle of that? | 13:47 |
| lkcl | yep if i remove that fieldsdb arg it works fine | 13:49 |
| lkcl | (not committed, i leave it to you) | 13:49 |
| ghostmansd | ah yeah I forgot to commit it | 14:28 |
| ghostmansd | sorry | 14:28 |
| ghostmansd | Should be better now | 14:28 |
| lkcl | doh :) | 14:43 |
| lkcl | ok i've put in a preliminary budget allocation under #254 for each of the 4 bugs | 14:44 |
| programmerjake | lkcl: the stuff you just added to the wiki about how SVP64 will achieve larger reg files by extending VSX...that needs to be a bit more generic, since we never finished the conversation about other ways to extend it...some of the ways I proposed don't need VSX at all... | 14:47 |
| lkcl | i know. it's a long story. | 14:48 |
| lkcl | i've been having confidential conversations and i can't tell you the contents | 14:48 |
| lkcl | but it resulted in | 14:48 |
| lkcl | https://www.youtube.com/watch?v=HNEm8zmkjBU | 14:48 |
| lkcl | and the realisation that under no circumstances can we permit register files to be extended arbitrarily | 14:49 |
| lkcl | it's perfectly fine if there's a completely separate prefix | 14:49 |
| lkcl | (a 25th bit) | 14:49 |
| programmerjake | the ways I proposed works because programs specifically opt-in to larger register files by setting some of the currently reserved bits in setvl (or a prefixed form of setvl) | 14:50 |
| lkcl | it's not in the least bit fine if the exact same binary can generate utterly different results on different hardware | 14:50 |
| lkcl | nope. | 14:50 |
| programmerjake | yup, none of my designs do that | 14:50 |
| lkcl | or... let me think about it... | 14:50 |
| lkcl | yes that might work | 14:50 |
| lkcl | because it's different SVSTATE. | 14:51 |
| lkcl | the catastrophic mistake that ARM SVE and RISC-V RVV have made - and i simply hadn't really noticed until last week - is that binaries are completely non-interoperable | 14:51 |
| lkcl | i mean | 14:51 |
| programmerjake | basically all I want at the moment is to change "SVP64 will extend VSX" to something like "SVP64 may choose to extend VSX" | 14:51 |
| lkcl | i _knew_ RVV was non-interoperable as far back as 2018 but the significance hadn't hit home | 14:52 |
| lkcl | yes good idea | 14:52 |
| programmerjake | if there are spare bits in SVSTATE currently, please ensure setting them results in traps, so they can be repurposed for later versions of SVP64 | 14:53 |
| lkcl | already done | 14:54 |
| lkcl | already required | 14:54 |
| programmerjake | yay! | 14:54 |
| programmerjake | your latest change looks good enough, thx! | 14:54 |
| lkcl | ngggh test_sv_ffadds_fft is failing | 14:56 |
| * lkcl dealing with it | 14:56 | |
| lkcl | that's interesting. it's because of MAXVL. | 14:57 |
| lkcl | doh. forgot to initialise maxvl in PowerDecoder2. doh | 14:59 |
| programmerjake | the table copying program is sufficiently completed -- I'm going to sleep now -- 7am: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=d07de16dd70b5d7a8f0cb75c7d510002c16c2628 | 15:00 |
| lkcl | ok :) | 15:01 |
| lkcl | nicely done | 15:01 |
| programmerjake | I tried to make it resilient so it won't destroy all our work, it saves backups and only overwrites at the very end it there's no errors. | 15:02 |
| programmerjake | and it has tons of error checks | 15:02 |
| programmerjake | probably over-engineered | 15:03 |
| lkcl | cooool https://libre-soc.org/openpower/power_trans_ops/ | 15:03 |
| programmerjake | I changed some of the descriptions to math formulae so they're less confusing | 15:04 |
| programmerjake | i forgot to have that be a separate commit though...sorry | 15:04 |
| lkcl | pffh, don't worry about it | 15:06 |
| lkcl | as long as pandoc recognises them | 15:06 |
| programmerjake | I forgot to check that too...but I'd be very surprised if pandoc doesn't -- they're standard xml/html | 15:07 |
| programmerjake | gn | 15:07 |
| programmerjake | though some of the rsqrt/cbrt/rootn stuff could probably look better by using latex's math support | 15:08 |
| lkcl | l.539 fatan2pi(s) & atan2 arc tangent / π | 15:11 |
| lkcl | ! Package inputenc Error: Unicode char ∈ (U+2208) | 15:11 |
| lkcl | (inputenc) not set up for use with LaTeX. | 15:11 |
| lkcl | i'll see if i can deal with that | 15:11 |
| programmerjake | thx! | 15:12 |
| lkcl | unicodemath package | 15:12 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 15:43 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.227> has joined #libre-soc | 15:44 | |
| sadoon[m] | heheh was wondering why my system feels slow. it's building the libre-soc stuff on all 80 threads | 16:03 |
| sadoon[m] | "./hdl-tools-yosys" | 16:03 |
| lkcl | well done :) | 16:05 |
| lkcl | yes i'm not very happy with the "make -j$nproc" | 16:05 |
| lkcl | it makes my laptop unresponsive | 16:05 |
| sadoon[m] | i'm happy tho | 16:11 |
| sadoon[m] | I didn't shell out that money for the cores to stay idling xD | 16:11 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.227> has quit IRC | 16:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:22 | |
| * lkcl cackles | 16:26 | |
| lkcl | ghostmansd, you'll see the taskdb is updated https://libre-soc.org/task_db/mdwn/ghostmansd/ | 16:27 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.196> has joined #libre-soc | 16:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.196> has quit IRC | 16:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:41 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:47 | |
| *** octavius <octavius!~octavius@109.125.93.209.dyn.plus.net> has joined #libre-soc | 17:05 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:06 | |
| ghostmansd | lkcl, cool! thank you! | 17:07 |
| ghostmansd | I'm not sure I'll be able to do all, but I'll try to do my best | 17:07 |
| ghostmansd | For dis, I think I already can submit RFP for scalar instructions and power_insn, if I decouple some of budget from 917 to its children. | 17:07 |
| ghostmansd | However, for now I'll concentrate on the tasks themselves. I think that after we got pysvp64dis working, supporting binutils would be way simpler, thanks to the generated getters/setters. | 17:07 |
| ghostmansd | lkcl, do we have some ready-to-use tests which check modes so that I could sneak into them and verify pysvp64dis output? | 17:08 |
| ghostmansd | God it's so sucking annoying to pass db instance into each and every method of SVP64Instruction... | 17:17 |
| ghostmansd | What do you say if we pass database instance upon construction instruction? | 17:18 |
| ghostmansd | This somewhat forces the caller, though... But we construct the database before, anyway. | 17:19 |
| lkcl | ghostmansd, well, basically what we do is, go "success! the tasks have been achieved! they were smaller tasks, but they were achieved" | 17:32 |
| lkcl | you get the drift? :) | 17:32 |
| lkcl | checking modes: what exactly are you looking for? because it occurred to me, just add some unit tests which assemble-then-disassemble | 17:33 |
| lkcl | if the results are the same that's good enough | 17:34 |
| lkcl | i.e. if you get back exactly what you started with | 17:34 |
| lkcl | passing db into every SVP64Instruction method instance? sounds like a classic case of passing it in to the constructor, to me | 17:35 |
| lkcl | or, the other way, have a "setdb()" method | 17:35 |
| lkcl | that's always a favourite, particularly if there's cross-dependency | 17:35 |
| ghostmansd | OK then, I'm going with passing it. | 17:43 |
| ghostmansd | Also, word instructions need it, too. | 17:43 |
| ghostmansd | Except for insn.svp64 part, obviously. | 17:43 |
| ghostmansd | For tests, yes, I'll add these. But for now I simply wanted to check that this LDSTImm/LDSTIdx/Normal modes detection works. | 17:45 |
| ghostmansd | I'm going to add printing the mode into the verbose mode. Actually this will be the first real SVP64-related bit for disassembly. | 17:45 |
| ghostmansd | And, well, having some "sv.INSN/SPEC0/SPEC2/... ARG0,ARG1,ARG2" stuff for checking if modes are handled correctly would be great. | 17:46 |
| ghostmansd | I mean, I _can_ reconstruct these and come up with some artificial examples, but that won't be honest. | 17:47 |
| ghostmansd | Since we have src/openpower/decoder/power_svp64_extra.py and src/openpower/decoder/power_decoder2.py and other stuff, perhaps we already check what it does? | 17:48 |
| ghostmansd | No, it won't be easy. All these classes downstream (Field, Array, Mapping) are instantiated upon request, dynamically. | 18:10 |
| ghostmansd | And I'll have to pass db instance to any of them. | 18:11 |
| ghostmansd | Fuck. One of the initial benefits (dealing on the same SelectableInt) turned out to be an obstacle.... | 18:11 |
| ghostmansd | All these bits like cls(storage) where cls can be a dynamic class... Holy cow. | 18:16 |
| ghostmansd | You know what? I'm keeping it. Thinking about how to handle it better now literally almost makes my head explode. | 18:17 |
| ghostmansd | And I won't lose the benefit of having the same SelectableInt all way round. | 18:17 |
| ghostmansd | So yeah, until I complete these tasks, we'll pass db to methods. After all, nobody will ever enter disassembly world without the database where we have all these bits of information essential to perform the disassembly. | 18:20 |
| ghostmansd | Also, pysvp64asm is going to "build" instruction... therefore the db record cannot be fixed. | 18:24 |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 19:11 | |
| lkcl | ghostmansd, well, unfortunately, i bypassed low-level unit testing for sv/trans/svp64.py and went straight to test_caller_*.py | 19:40 |
| lkcl | dis branch ok to rebase after testing? | 19:43 |
| ghostmansd[m] | Yeah I think so | 20:07 |
| ghostmansd[m] | Not that much to rebase, though | 20:07 |
| ghostmansd[m] | So you might postpone it | 20:07 |
| lkcl | ok | 20:12 |
| lkcl | passed anyway | 20:12 |
| lkcl | eh what the heck, did it anyway. branches make me nervous and i have some things to do for parallel-prefix | 20:13 |
| lkcl | parallel-reduction | 20:13 |
| ghostmansd[m] | Ok then :-) | 20:25 |
| ghostmansd[m] | I lost the most of the day hunting this name lookup. Anyway, the hope is that I'll be able to continue SVP64 decoding next. | 20:26 |
| lkcl | brilliant. | 20:26 |
| ghostmansd[m] | I think the next step will be to decode operands... | 20:28 |
| ghostmansd[m] | What'd be the best way to approach type of the register? | 20:28 |
| ghostmansd[m] | Say whether it's vector or not, size, etc. | 20:28 |
| ghostmansd[m] | I recall some bits go to extras | 20:29 |
| ghostmansd[m] | But I could only recall the bits used for "size" of the operand. | 20:29 |
| ghostmansd[m] | And the state, whether it's vector, that's what bothers me. | 20:29 |
| lkcl | first, you have to know the type of the encoding. whether it is EXTRA2 or EXTRA3. | 20:30 |
| ghostmansd[m] | I also recall that depending on whether it's a vector, we change the way we put the bits (basically with shifts and similar). | 20:30 |
| ghostmansd[m] | PTYPE? | 20:30 |
| lkcl | remember, that's all in the RM-1/2P-NSND.csv files | 20:30 |
| lkcl | no, that's the predicate type (P for predicate) | 20:31 |
| lkcl | 1 sec | 20:31 |
| lkcl | Etype is whether the encoding is EXTRA2 or EXTRA3. | 20:31 |
| lkcl | this tells you whether to subdivide RM.EXTRA into 2-bit chunks or 3-bit chunks | 20:32 |
| ghostmansd[m] | Aaah rriight | 20:32 |
| ghostmansd[m] | Ok that's known in both binutils and pysvp64dis. | 20:32 |
| lkcl | then you look at the csv columns 0,1,2,3 | 20:32 |
| lkcl | and for EXTRA2 that will be bits 0-1 / 2-3 / 4-5 / 6-7 respectively | 20:32 |
| lkcl | for EXTRA3 it will be bits 0-2 / 3-5 / 6-8 | 20:33 |
| ghostmansd[m] | if extra3_mode: | 20:33 |
| ghostmansd[m] | spec = EXTRA3 | 20:33 |
| ghostmansd[m] | else: | 20:33 |
| ghostmansd[m] | spec = EXTRA2 << 1 # same as EXTRA3, shifted | 20:33 |
| ghostmansd[m] | if spec[0]: # vector | 20:33 |
| ghostmansd[m] | return (RA << 2) | spec[1:2] | 20:33 |
| ghostmansd[m] | else: # scalar | 20:33 |
| ghostmansd[m] | return (spec[1:2] << 5) | RA | 20:33 |
| lkcl | yep. | 20:33 |
| lkcl | that's it | 20:33 |
| ghostmansd[m] | This is it, right? | 20:33 |
| ghostmansd[m] | Ok should be sufficient | 20:33 |
| ghostmansd[m] | Well at least for the start | 20:33 |
| ghostmansd[m] | spec = EXTRA2 << 1 # same as EXTRA3, shifted | 20:36 |
| ghostmansd[m] | We then get spec[0] | 20:36 |
| ghostmansd[m] | [0] is (spec & 1), or ((spec >> 1) & 1)? | 20:36 |
| lkcl | yes but only for vectors, iirc. | 20:37 |
| ghostmansd[m] | That is, 0 counting from where? | 20:37 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/#index12h1 | 20:37 |
| lkcl | 1 sec | 20:37 |
| lkcl | see INT/FP EXTRA3 | 20:38 |
| lkcl | and INT/FP EXTRA2 | 20:38 |
| lkcl | start with scalar, start with 5-bit GPR/FPR number. | 20:39 |
| lkcl | EXTRA2, there is only one extra bit and spec[0] is zero | 20:39 |
| lkcl | therefore spec[1] is made to be the 6th bit | 20:40 |
| lkcl | and the 7th bit is set to zero | 20:40 |
| lkcl | EXTRA3: there are *two* bits available. spec[0] is still zero (we are talking scalar) | 20:40 |
| lkcl | therefore, spec[1] and spec[2] provide the sixth AND seventh bits respectively | 20:40 |
| lkcl | for Vector numbering you still start with 5-bit GPR/FPR number but you want the EXTRA2 to still be able to do higher numbers | 20:41 |
| lkcl | so you sacrifice the ***LOWER*** bit range unlike the scalar which sacrifices the ***UPPER*** bit range | 20:41 |
| lkcl | therefore | 20:42 |
| lkcl | for EXTRA2 | 20:42 |
| lkcl | there is only one extra bit, and spec[0] is ONE this time (vector) | 20:42 |
| lkcl | therefore spec[1] is made to be the **SECOND** bit | 20:42 |
| lkcl | the first bit is ***ZERO*** | 20:42 |
| lkcl | and bits three to seven are the original 5-bits RA/RB/RC/RT/RS | 20:42 |
| lkcl | oh look | 20:43 |
| lkcl | vector: return (RA << 2) | spec[1:2] | 20:43 |
| lkcl | it's all there. | 20:43 |
| ghostmansd[m] | Ok will check tomorrow, with a fresh head | 20:45 |
| lkcl | cool. | 20:46 |
| *** octavius <octavius!~octavius@109.125.93.209.dyn.plus.net> has quit IRC | 21:00 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 22:19 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 22:25 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 22:25 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 22:29 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!