Sunday, 2022-09-04

*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC03:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc03:42
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC06:02
*** yambo <yambo!~yambo@> has quit IRC06:02
*** toshywoshy <toshywoshy!> has quit IRC06:02
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC06:02
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC06:02
*** lkcl <lkcl!> has quit IRC06:02
*** mx08 <mx08!~mx08@user/mx08> has quit IRC06:02
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC06:02
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC06:02
*** midnight <midnight!~midnight@user/midnight> has quit IRC06:02
*** hl <hl!~hl@user/hl> has quit IRC06:02
*** philpax_ <philpax_!> has quit IRC06:02
*** sauce <sauce!> has quit IRC06:02
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc06:03
*** yambo <yambo!~yambo@> has joined #libre-soc06:03
*** toshywoshy <toshywoshy!> has joined #libre-soc06:03
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc06:03
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc06:03
*** lkcl <lkcl!> has joined #libre-soc06:03
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc06:03
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc06:03
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc06:03
*** midnight <midnight!~midnight@user/midnight> has joined #libre-soc06:03
*** hl <hl!~hl@user/hl> has joined #libre-soc06:03
*** philpax_ <philpax_!> has joined #libre-soc06:03
*** sauce <sauce!> has joined #libre-soc06:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:06
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:06
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:06
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC06:06
*** yambo <yambo!~yambo@> has quit IRC06:06
*** toshywoshy <toshywoshy!> has quit IRC06:06
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC06:06
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC06:06
*** lkcl <lkcl!> has quit IRC06:06
*** mx08 <mx08!~mx08@user/mx08> has quit IRC06:06
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC06:06
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC06:06
*** midnight <midnight!~midnight@user/midnight> has quit IRC06:06
*** hl <hl!~hl@user/hl> has quit IRC06:06
*** philpax_ <philpax_!> has quit IRC06:06
*** sauce <sauce!> has quit IRC06:06
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC06:06
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC06:06
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC06:06
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC06:06
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC06:06
*** ckie <ckie!~ckie@user/cookie> has quit IRC06:06
*** josuah <josuah!~irc@> has quit IRC06:06
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC06:06
*** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC06:06
*** rsc <rsc!~robert@fedora/rsc> has quit IRC06:06
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:06
*** sauce <sauce!> has joined #libre-soc06:06
*** philpax_ <philpax_!> has joined #libre-soc06:06
*** hl <hl!~hl@user/hl> has joined #libre-soc06:06
*** midnight <midnight!~midnight@user/midnight> has joined #libre-soc06:06
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc06:06
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc06:06
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc06:06
*** lkcl <lkcl!> has joined #libre-soc06:06
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc06:06
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc06:06
*** toshywoshy <toshywoshy!> has joined #libre-soc06:06
*** yambo <yambo!~yambo@> has joined #libre-soc06:07
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc06:07
*** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc06:07
*** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc06:07
*** josuah <josuah!~irc@> has joined #libre-soc06:07
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc06:07
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc06:07
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc06:07
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc06:07
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc06:07
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc06:07
*** ckie <ckie!~ckie@user/cookie> has joined #libre-soc06:07
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:07
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:07
*** openpowerbot <openpowerbot!> has quit IRC06:07
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC06:07
*** openpowerbot <openpowerbot!> has joined #libre-soc06:07
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC06:08
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC06:08
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC06:08
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC06:08
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC06:10
*** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC06:10
*** rsc <rsc!~robert@fedora/rsc> has quit IRC06:10
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc06:10
*** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc06:10
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC06:10
*** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc06:10
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc06:13
*** openpowerbot <openpowerbot!> has quit IRC06:13
*** ckie <ckie!~ckie@user/cookie> has quit IRC06:13
*** josuah <josuah!~irc@> has quit IRC06:13
*** openpowerbot <openpowerbot!> has joined #libre-soc06:14
*** ckie <ckie!~ckie@user/cookie> has joined #libre-soc06:14
*** josuah <josuah!~irc@> has joined #libre-soc06:14
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC06:14
*** openpowerbot <openpowerbot!> has quit IRC06:14
*** openpowerbot <openpowerbot!> has joined #libre-soc06:15
*** openpowerbot <openpowerbot!> has quit IRC06:19
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc06:34
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc06:42
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc06:42
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc06:50
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:31
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc08:31
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc08:31
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc09:00
*** ghostmansd <ghostmansd!> has joined #libre-soc10:08
ghostmansdlkcl, I've restored target_addr. I checked  and, 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
ghostmansdLet me know if any problems come up.10:11
ghostmansdMeanwhile I'll support stuff like D(RA).10:11
ghostmansdOK done10:27
ghostmansdThere's however one quirk which must be updated, too10:28
ghostmansdHm. Perhaps I'll refactor it.10:28
lkclprogrammerjake, nicely gone on reallocation of ffmadds etc. you saw ghostmansd and i sorted out creating a mdwn table from the csv files?10:49
lkclit's reaall basic at the moment10:49
lkclbut functional10:49
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:49
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:50
lkclghostmansd, one thing that is "Bad(tm)" though is: a not-infrequent number of times the "conflict" alert gets raised10:51
lkclbut it's random (!)10:51
lkcl  File "decoder/", line 83, in do_table10:51
lkclAssertionError: entry 0 1 should be empty contains rldic conflicting rldicl10:51
lkcl2nd run:10:51
programmerjakeah, 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 table10:52
lkclprogrammerjake, that's already been done.10:52
ghostmansdlkcl, I don't quite get what you mean by conflict10:52
lkclplease don't duplicate work10:52
ghostmansdcould you, please, share a bit more in details?10:53
lkcland please discuss these things with me.10:53
programmerjakelkcl: 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
ghostmansdI have literally no idea what lower and upper mean10:53
ghostmansdand what "table_entries" stand for10:53
lkclthe lower half of the XO and the upper half of the XO10:54
programmerjakeand puts the XO codes in | fatan2pi(s)| atan2 arc tangent / &pi;                | 10000 01110     |10:54
lkclprogrammerjake, ok that would work well10:54
lkclghostmansd, so the table_entries is a 2D dictionary of rows-columns which gets print()ed as a markdown table10:54
programmerjakeso, to clarify, I'm not duplicating work rn?10:55
lkclprogrammerjake, well, kind-of10:55
lkclwe literally just did CSV-reading last night, or, using ghostmansd's PowerISA database-reader10:56
programmerjakeiirc the code you're writing goes from .csv files to markdown tables...10:56
programmerjakemy code goes from markdown tables to markdown tables10:56
lkclit would be better to rip out the markdown tables entirely and autogenerate them10:56
lkclthen drop them into an underlay as an automated command10:57
programmerjakemaybe, but I like editing markdown tables best when I'm deciding what goes where...10:57
lkclyeah that sounds reasonable, i do as well10:57
programmerjakea simple regex can convert the results to the csv format10:57
programmerjakethat's what I did when I found the overlap10:58
programmerjakeregex, then sort lines10:58
lkclprogrammerjake, is intended to re-create the Appendix tables so that we're certain there's no overlaps across multiple instructions being designed/added10:59
lkclwhich i totally forgot to check10:59
programmerjakeI moved ffmadds...10:59
lkclghostmansd, so what does is literally walk through every single binary number 0b00000000 to 0b1111111110:59
lkcland create a lower-half mask and an upper-half mask10:59
lkclprogrammerjake, yes i saw. good call on X-Form.11:00
programmerjakeuuh, I'm assuming you want 10-bit numbers there, not 8-bit11:00
lkclthe lower-half is the row-number, the upper-half is the column number (something like that)11:00
lkclprogrammerjake, it's read from insndb.csv11:00
programmerjakeah, k11:00
lkclso minor_30 is 4-bit (picked because it's smaller)11:00
lkcli tried minor_22 holy cow the table was massive.  11-bit11:01
ghostmansdOK I'm done with immediate operands11:08
ghostmansdThey end up with a standalone entry in operands, but now print correctly in the whole spec11:09
ghostmansd example11:10
ghostmansdOK, now on to power_table.py11:10
ghostmansdAll discussion here is somewhat mixed with comments on several topics :-)11:10
ghostmansdAgain, what's the issue and what exactly do you check with this assertion?11:11
lkclis there a conflict, yes no.11:11
lkclconflict: two instructions attempt to go in same XO11:11
lkclrun  python3 decoder/ ten times11:12
lkclyou should find that appx 4/6 times, an assert is called. clearly that's catastrophic.11:13
lkclah i just noticed11:13
ghostmansdLikely it depends on the order of entries.11:14
lkclwhen it occurs, it's actually the case that the two PatternOpcodes are in fact the same11:14
lkclop rldic PatternOpcode(value=0x00000004, mask=0x0000000e)11:14
lkclop rldicl PatternOpcode(value=0x00000004, mask=0x0000000e)11:14
lkclAssertionError: entry 0 1 (XO 0b100) should be empty contains rldic conflicting rldicl11:14
ghostmansdThis shouldn't happen, they should've ended with different patterns.11:15
ghostmansdOK, I'm checking this.11:15
lkcloh i worked out how to use PPCMultiRecord, it was dead simple. not obvious (inheriting from tuple) but simple to use11:16
ghostmansdwell this was the simplest option11:16
lkclyes, works well11:17
lkclprogrammerjake, no instruction may be unique in the 64-bit space.11:20
ghostmansdThis code
ghostmansdprints this
lkclnow run it 10 times11:21
ghostmansdAaaah I see11:21
ghostmansdThe pattern changes11:21
ghostmansdLikely it's caused by the way the merge is implemented and depends on the particular order11:22
ghostmansdYes it's caused by the set mutable order11:28
lkclgood thing that was found :)11:28
ghostmansdBut also the merge is likely broken, it should've given same result regardless of the order11:28
ghostmansdCould you, please, take a look at it?11:28
ghostmansdI'm not sure how to approach it better.11:29
ghostmansdWhat 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
ghostmansdThen it tries to produce a new PPCRecord with the replaced opcode.11:30
lkclahhh it has to be done in one hit, not as a merge11:32
ghostmansdWhat do you mean, in one hit?11:33
ghostmansdThere're multiple records, we have to iterate anyway.11:33
lkclnot using reduce.11:34
lkclthe entire batch has to be analysed in one go.11:34
lkclreduce will do merge(1,merge(2,merge(3,merge(4,merge(5,6)))))11:34
lkclwhat's needed is:11:35
lkclglobal initial value=011:35
lkclglobal initial mask = 011:35
lkclfor insn in list_of_opcodes:11:35
lkcl     for each bit11:35
lkcl            ....11:35
lkclthe ordering of those merge()s could end up11:36
lkcland the intermediary results end up completely wrong (i don't entirely know how)11:37
ghostmansdYeah, but we simply check if the bits differ on the previous stage, don't we?11:37
ghostmansd*from the previous stage11:37
ghostmansdOK, let's simplify the task11:37
lkclwait... hang on... we're talking masks here.  single-entry masks11:37
ghostmansdAssuming we have only two opcodes.11:37
lkclreduce on a single-entry shouldn't even *activate* this code11:38
lkclreduce([anything]) should always return [anything]11:38
lkclprogrammerjake, ffmadds etc. all have implicit RS regs because they're 3-in 2-out11:40
lkclyou just have to be "aware" of that. there's nothing that can be done about it - no "safety" net11:40
programmerjakeI knew that, did I mess something up?11:41
programmerjakek, good11:42
lkclit's the bugreport comment "fix the hack" that i found a little irritating11:42
lkclbecause it's good enough for now and needs considerable work to create mini-power-decoders11:43
programmerjakeoh, 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 enough11:44
lkclit should be more likely called "3in2out" or something as that's what it's for11:45
lkclthere will be more like that11:45
programmerjakei 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 failed11:46
programmerjaketo make it consistent with the state before I moved the instructions11:46
lkclgrr, i hate adding extra csv columns, it hits every single file.11:47
programmerjakeno 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 value11:47
programmerjakelike my_dict.get("key", my_default)11:48
programmerjakeiirc there are several columns that already do that11:48
programmerjakerather than "3in2out" i'd name it "implicit RS out" or similar11:49
programmerjakename it for what it does, rather than what properties usually enable it11:50
programmerjakesince I'd expect there might eventually be ops with implicit RS out that aren't 3-in 2-out11:50
lkclthere's EA from ld-st-with-update.11:52
lkcl            # update mode LD/ST uses read-reg A also as an output11:53
lkcl            with m.If(op.upd == LDSTMode.update):11:53
lkcl                comb +=
programmerjakeimho ldu is different than implicit RS out ops, since it usually writes back to the same register, rather than writing to a different register11:53
programmerjakeldu is more like the rotate immediate something-or-other op that reads RT and writes RT11:54
lkclyyep just looking at DecodeOut2 it's using a bit fp_madd_en to decode whether to offset RS by VL11:55
lkclerr that should be maxvl, damn11:55
lkclwhoaaaa 70 simulator test failures11:56
lkcl    entries = filter(lambda entry: "TODO" \11:57
lkcl>                    not in frozenset(entry.values()), entries)11:57
lkclE   TypeError: unhashable type: 'list'11:57
lkcl../ TypeError11:57
lkcl../../test/algorithms/ in program11:57
lkcl    return assemble(svp64_utf8_validation_asm())11:57
lkclthat sounds/seems like an honest double-commit conflict11:58
programmerjakeidk what caused that, but it passed CI when I committed11:58
lkclwhat git commit are you on?11:59
ghostmansdCould it be me?11:59
lkcli'm not interested in the job number, i need to know what commit you are currently on - what the master branch is12:00
lkclghostmansd, possibly, with the immediate operands refactoring12:00
programmerjakeyou can see what commit it is by looking at that url12:00
ghostmansdhm, doesn't look like it's the actual version: line 1259 doesn't seem right12:00
lkclfer f's sake.12:01
programmerjakethe last passed commit in CI is 04dad392 (not what I linked to)12:01
lkclthose URLs overload my machine(s)12:01
lkclok great. that leaves two possible commits12:01
programmerjake (won't overload your phone)12:01
ghostmansdline 1259 of is `class MarkdownDatabase:`12:02
ghostmansdah wait12:02
ghostmansdthere's more commits, I needed to pull12:02
programmerjakeI'm working on libreriscv.git, so that's probably my last commit to openpower-isa.git tonight...12:03
ghostmansdLuke, was this whitespace cleanup completely necessary now?12:03
lkclprogrammerjake, ok12:03
ghostmansdOK something gone wrong with CSVs it seems12:03
ghostmansdwhat to run to reproduce?12:04
programmerjakedid you forget to run `make`?12:04
lkclohhh hang on - sv_analysis might need running12:05
programmerjakeI changed opcodes, it needs to be run12:05
lkclit updates the svp64 CSV files so should *always* be done and committed at the time that the 32-bit CSV files are altered12:06
ghostmansdentries = filter(lambda entry: "TODO" \12:06
ghostmansd                     not in frozenset(entry.values()), entries)12:06
programmerjakeimho just get in the habit of running make after git pull --ff-only -- it only takes like 15s12:06
lkclbit it's ok - no change needed12:06
ghostmansdSeriously, such whitespace cleanup hurts even more than lack of it.12:06
lkclbecause, ha, the rest of the columns didn't change12:06
lkclghostmansd, then it should be done on 2 lines rather than one12:06
ghostmansdThen do it properly, not in an automatic way which breaks in completely unconvenient place12:07
lkclgimme 1 sec12:07
ghostmansdI'll do it12:07
ghostmansdThroughout the whole code I inserted indentation manually12:08
ghostmansdFor God's sake, simply indent by level12:08
ghostmansdNot by some goddamn = sign12:08
ghostmansdOr "TODO" keyword12:08
ghostmansdPfff, let me chill and simply strange at the code12:09
* lkcl running on commit 04dad3912:11
lkclf1865fb853 is next, then f4a7f0a7d71 after that.12:11
lkcltakes a long time, could do with some kind of reporting to be able to cut out some of the cases12:12
programmerjakelkcl: try testing src/openpower/decoder/isa/, it fails with TypeError during setup on c0484ef612:15
programmerjakeshould be much faster12:15
lkclprogrammerjake, yes just found that one12:15
lkcla lot frickin faster12:17
programmerjakeyeah, cuz utf-8 validation runs like 1500 test cases of a whole function12:17
lkclfaaakin'ellfire :)12:17
lkclthat's going on the "slow" list :)12:18
programmerjakehence why I added code to split it up into 64 (? icr) subtests so they can be run in parallel12:18
programmerjakeok, not self.subTest, but separate test entry functions that run part of the test case list12:19
lkclparallelism is of absolutely no use here when running on a machine where the loadavg goes up to 25 if doing so and becomes unresponsibe12:19
lkclyou *can't* assume that everyone's machines are the same12:19
programmerjakeparallelism 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 time12:20
programmerjakeso if your machine goes to loadaverage 25, then pick a smaller number than pytest -n 2512:21
lkcli'm not using pytest for individual runs12:21
lkclplease just don't make assumptions that tests *must* be run in parallel12:21
lkclat all12:21
programmerjakeif you use unittest, it doesn't run anything in parallel. if you run nose, it has a similar option to pytest12:22
lkclwe need a range of *fast* tests as well as comprehensive ones, ok?12:22
lkcli run the test directly as a command.12:22
lkcli don't expect it to take 15 minutes to complete because of assumptions "it must be run in parallel"12:22
programmerjakerunning it directly gets you unittest, which should be singlethreaded12:22
lkclso it would be better to have 20 separate .py files than it would to make the assumption that one file *must* run massive parallelism12:23
programmerjakeit 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
lkclthat way it's possible to run just the one file12:23
lkclthere's nothing wrong, now.12:24
ghostmansdOK I pushed the whitespace cleanup12:24
lkcli ran the individual test - on master - and it's passing12:24
programmerjakeif you want to just run 1 subtest, just run TestSVP64UTF8Validation012:24
ghostmansdNext time, please, don't do it that way you did.12:24
lkclhow am i supposed to know that?12:24
lkclghostmansd, ack12:24
ghostmansdAnd, if you're really bothered, let's setup a hook, for God's sake12:25
ghostmansdI've been developing it for too many days already, I cannot keep an attention for each and every single line.12:25
ghostmansdSo, we might establish a hook which prevents this to be pushed.12:25
lkclunfortunately there's places where off-the-internet URLs overrun and there's nothing that can be done about that12:26
programmerjakelkcl: because it's standard unittest interface, so you can always pass a subtest filter list12:26
lkcl(not without breaking up the URL, which is worse)12:26
ghostmansdOK back to opcodes merge.12:26
lkclok so we've a situation where pytest fails but the same individual unit test does not12:26
lkclahhh i'm going to re-run the test multiple times12:27
programmerjakeis it a case of subtly depending on soc again?12:27
programmerjakeor maybe it doesn't like running in parallel because someone assumed only 1 process would run at a time?12:27
programmerjakestandard practice for me and for CI is to assume process-level parallelism12:28
lkclno, sigh, it's a case of me being dumb and running the wrong damn test :)12:28
lkclnot test_caller_svp64_alu.py12:28
* lkcl face-palm12:29
lkclokaaaay. repro12:29
programmerjakeI'd just type ctrl+R to get the last time I ran a test...12:29
programmerjakeassuming your repeating the same test12:29
lkclcommit 611e5 good12:30
lkclprogrammerjake, i typed it out manually the 1st time12:30
lkclcommit f43c616a good12:30
ghostmansdOK I have a minimal reproducer for opcodes issue and can debug it now12:31
lkclghostmansd, fantastic12:31
lkclahh utterly stupid of me.12:34
lkclin the comment on the csv file i added a comma12:35
* lkcl facepalm12:35
programmerjakeuuh, don't you strip comments before parsing csv?12:35
programmerjakealso commas were there when I tested and it worked...12:36
lkclis interpreted as12:36
lkclfield,field,commment-first-half,comment-second-half12:36 mean the comment field, not a # my goofy comment!!12:36
programmerjakeall you need is "12:37
lkclbtw folks i spoke to michiel and he's ok with reallocating the budget of #241.12:40
lkcl#254 sorry12:40
lkclwhich is a continuation task anyway but with a primary focus on 3D12:40
programmerjakeyeah, we're nowhere close enough to do that...sadly12:41
lkclwhich is why i asked if it could be reallocated, and he said yes12:42
ghostmansdI think I know13:04
ghostmansdIt's the name matching algorithm13:05
ghostmansdIt sees "l" in the end for stuff like rldicl13:06
ghostmansdAnd, well, it matches rldic or rldicl13:06
ghostmansdSometimes one, sometimes another13:07
ghostmansdOK, we must first check for the exact match, and only then try the loosy ones13:08
ghostmansdlkcl, please try again13:12
ghostmansdAt least this shouldn't heisenbug us anymore13:13
ghostmansdBy the way, all suggestions on how to improve and/or fix the matching are more than welcome.13:14
ghostmansdlkcl, beware: I'm going to change PPCDatabase constructor so that it no longer takes redundant parameter (a leftover from some debug session).13:21
ghostmansdYou know what? Nevermind, I'll simply update power_table for you.13:22
ghostmansddb = Database(root)13:28
ghostmansdfor insn in db:13:28
ghostmansd    insns[str(insn.section.path)].append(insn)13:28
ghostmansd    print (insn)13:28
ghostmansdI'll also simplify the code13:28
ghostmansdlkcl, done, also replaced all prints with log (except for the table itself)13:34
ghostmansdping me if you need help rebasing13:35
ghostmansd^ what we have when we run power_table script with SILENCELOG=true13:36
ghostmansdOK let the Dobby proceed with SVP64 disassembly now13:37
lkclghostmansd, ahh that'll do it :)13:46
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 1429, in __init__13:47
lkcl    ppcdb = PPCDatabase(root=root, mdwndb=mdwndb, fieldsdb=fieldsdb)13:47
lkclok. i take it you're in the middle of that?13:47
lkclyep if i remove that fieldsdb arg it works fine13:49
lkcl(not committed, i leave it to you)13:49
ghostmansdah yeah I forgot to commit it14:28
ghostmansdShould be better now14:28
lkcldoh :)14:43
lkclok i've put in a preliminary budget allocation under #254 for each of the 4 bugs14:44
programmerjakelkcl: 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
lkcli know. it's a long story.14:48
lkcli've been having confidential conversations and i can't tell you the contents14:48
lkclbut it resulted in14:48
lkcland the realisation that under no circumstances can we permit register files to be extended arbitrarily14:49
lkclit's perfectly fine if there's a completely separate prefix14:49
lkcl(a 25th bit)14:49
programmerjakethe 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
lkclit's not in the least bit fine if the exact same binary can generate utterly different results on different hardware14:50
programmerjakeyup, none of my designs do that14:50
lkclor... let me think about it...14:50
lkclyes that might work14:50
lkclbecause it's different SVSTATE.14:51
lkclthe 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-interoperable14:51
lkcli mean14:51
programmerjakebasically all I want at the moment is to change "SVP64 will extend VSX" to something like "SVP64 may choose to extend VSX"14:51
lkcli _knew_ RVV was non-interoperable as far back as 2018 but the significance hadn't hit home14:52
lkclyes good idea14:52
programmerjakeif there are spare bits in SVSTATE currently, please ensure setting them results in traps, so they can be repurposed for later versions of SVP6414:53
lkclalready done14:54
lkclalready required14:54
programmerjakeyour latest change looks good enough, thx!14:54
lkclngggh test_sv_ffadds_fft is failing14:56
* lkcl dealing with it14:56
lkclthat's interesting. it's because of MAXVL.14:57
lkcldoh. forgot to initialise maxvl in PowerDecoder2. doh14:59
programmerjakethe table copying program is sufficiently completed -- I'm going to sleep now -- 7am:;a=commitdiff;h=d07de16dd70b5d7a8f0cb75c7d510002c16c262815:00
lkclok :)15:01
lkclnicely done15:01
programmerjakeI 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
programmerjakeand it has tons of error checks15:02
programmerjakeprobably over-engineered15:03
programmerjakeI changed some of the descriptions to math formulae so they're less confusing15:04
programmerjakei forgot to have that be a separate commit though...sorry15:04
lkclpffh, don't worry about it15:06
lkclas long as pandoc recognises them15:06
programmerjakeI forgot to check that too...but I'd be very surprised if pandoc doesn't -- they're standard xml/html15:07
programmerjakethough some of the rsqrt/cbrt/rootn stuff could probably look better by using latex's math support15:08
lkcll.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
lkcli'll see if i can deal with that15:11
lkclunicodemath package15:12
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:43
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:44
sadoon[m]heheh was wondering why my system feels slow. it's building the libre-soc stuff on all 80 threads16:03
lkclwell done :)16:05
lkclyes i'm not very happy with the "make -j$nproc"16:05
lkclit makes my laptop unresponsive16:05
sadoon[m]i'm happy tho16:11
sadoon[m]I didn't shell out that money for the cores to stay idling xD16:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:21
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:22
* lkcl cackles16:26
lkclghostmansd, you'll see the taskdb is updated
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:27
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:40
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:41
*** ghostmansd <ghostmansd!> has quit IRC16:47
*** octavius <octavius!> has joined #libre-soc17:05
*** ghostmansd <ghostmansd!> has joined #libre-soc17:06
ghostmansdlkcl, cool! thank you!17:07
ghostmansdI'm not sure I'll be able to do all, but I'll try to do my best17:07
ghostmansdFor 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
ghostmansdHowever, 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
ghostmansdlkcl, do we have some ready-to-use tests which check modes so that I could sneak into them and verify pysvp64dis output?17:08
ghostmansdGod it's so sucking annoying to pass db instance into each and every method of SVP64Instruction...17:17
ghostmansdWhat do you say if we pass database instance upon construction instruction?17:18
ghostmansdThis somewhat forces the caller, though... But we construct the database before, anyway.17:19
lkclghostmansd, well, basically what we do is, go "success! the tasks have been achieved! they were smaller tasks, but they were achieved"17:32
lkclyou get the drift? :)17:32
lkclchecking modes: what exactly are you looking for?  because it occurred to me, just add some unit tests which assemble-then-disassemble17:33
lkclif the results are the same that's good enough17:34
lkcli.e. if you get back exactly what you started with17:34
lkclpassing db into every SVP64Instruction method instance? sounds like a classic case of passing it in to the constructor, to me17:35
lkclor, the other way, have a "setdb()" method17:35
lkclthat's always a favourite, particularly if there's cross-dependency17:35
ghostmansdOK then, I'm going with passing it.17:43
ghostmansdAlso, word instructions need it, too.17:43
ghostmansdExcept for insn.svp64 part, obviously.17:43
ghostmansdFor tests, yes, I'll add these. But for now I simply wanted to check that this LDSTImm/LDSTIdx/Normal modes detection works.17:45
ghostmansdI'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
ghostmansdAnd, well, having some "sv.INSN/SPEC0/SPEC2/... ARG0,ARG1,ARG2" stuff for checking if modes are handled correctly would be great.17:46
ghostmansdI mean, I _can_ reconstruct these and come up with some artificial examples, but that won't be honest.17:47
ghostmansdSince we have src/openpower/decoder/ and src/openpower/decoder/ and other stuff, perhaps we already check what it does?17:48
ghostmansdNo, it won't be easy. All these classes downstream (Field, Array, Mapping) are instantiated upon request, dynamically.18:10
ghostmansdAnd I'll have to pass db instance to any of them.18:11
ghostmansdFuck. One of the initial benefits (dealing on the same SelectableInt) turned out to be an obstacle....18:11
ghostmansdAll these bits like cls(storage) where cls can be a dynamic class... Holy cow.18:16
ghostmansdYou know what? I'm keeping it. Thinking about how to handle it better now literally almost makes my head explode.18:17
ghostmansdAnd I won't lose the benefit of having the same SelectableInt all way round.18:17
ghostmansdSo 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
ghostmansdAlso, pysvp64asm is going to "build" instruction... therefore the db record cannot be fixed.18:24
*** choozy <choozy!> has joined #libre-soc19:11
lkclghostmansd, well, unfortunately, i bypassed low-level unit testing for sv/trans/ and went straight to test_caller_*.py19:40
lkcldis branch ok to rebase after testing?19:43
ghostmansd[m]Yeah I think so20:07
ghostmansd[m]Not that much to rebase, though20:07
ghostmansd[m]So you might postpone it20:07
lkclpassed anyway20:12
lkcleh what the heck, did it anyway. branches make me nervous and i have some things to do for parallel-prefix20: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
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 extras20: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
lkclfirst, 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
lkclremember, that's all in the RM-1/2P-NSND.csv files20:30
lkclno, that's the predicate type (P for predicate)20:31
lkcl1 sec20:31
lkclEtype is whether the encoding is EXTRA2 or EXTRA3.20:31
lkclthis tells you whether to subdivide RM.EXTRA into 2-bit chunks or 3-bit chunks20:32
ghostmansd[m]Aaah rriight20:32
ghostmansd[m]Ok that's known in both binutils and pysvp64dis.20:32
lkclthen you look at the csv columns 0,1,2,320:32
lkcland for EXTRA2 that will be bits 0-1 / 2-3 / 4-5 / 6-7 respectively20:32
lkclfor EXTRA3 it will be bits 0-2 / 3-5 / 6-820:33
ghostmansd[m]if extra3_mode:20:33
ghostmansd[m]    spec = EXTRA320:33
ghostmansd[m]    spec = EXTRA2 << 1 # same as EXTRA3, shifted20:33
ghostmansd[m]if spec[0]: # vector20:33
ghostmansd[m]     return (RA << 2) | spec[1:2]20:33
ghostmansd[m]else:         # scalar20:33
ghostmansd[m]     return (spec[1:2] << 5) | RA20:33
lkclthat's it20:33
ghostmansd[m]This is it, right?20:33
ghostmansd[m]Ok should be sufficient20:33
ghostmansd[m]Well at least for the start20:33
ghostmansd[m]spec = EXTRA2 << 1 # same as EXTRA3, shifted20:36
ghostmansd[m]We then get spec[0]20:36
ghostmansd[m][0] is (spec & 1), or ((spec >> 1) & 1)?20:36
lkclyes but only for vectors, iirc.20:37
ghostmansd[m]That is, 0 counting from where?20:37
lkcl1 sec20:37
lkclsee INT/FP EXTRA320:38
lkcland INT/FP EXTRA220:38
lkclstart with scalar, start with 5-bit GPR/FPR number.20:39
lkclEXTRA2, there is only one extra bit and spec[0] is zero20:39
lkcltherefore spec[1] is made to be the 6th bit20:40
lkcland the 7th bit is set to zero20:40
lkclEXTRA3: there are *two* bits available.  spec[0] is still zero (we are talking scalar)20:40
lkcltherefore, spec[1] and spec[2] provide the sixth AND seventh bits respectively20:40
lkclfor Vector numbering you still start with 5-bit GPR/FPR number but you want the EXTRA2 to still be able to do higher numbers20:41
lkclso you sacrifice the ***LOWER*** bit range unlike the scalar which sacrifices the ***UPPER*** bit range20:41
lkclfor EXTRA220:42
lkclthere is only one extra bit, and spec[0] is ONE this time (vector)20:42
lkcltherefore spec[1] is made to be the **SECOND** bit20:42
lkclthe first bit is ***ZERO***20:42
lkcland bits three to seven are the original 5-bits RA/RB/RC/RT/RS20:42
lkcloh look20:43
lkclvector: return (RA << 2) | spec[1:2]20:43
lkclit's all there.20:43
ghostmansd[m]Ok will check tomorrow, with a fresh head20:45
*** octavius <octavius!> has quit IRC21:00
*** lkcl <lkcl!> has quit IRC22:19
*** choozy <choozy!> has quit IRC22:25
*** choozy <choozy!> has joined #libre-soc22:25
*** lkcl <lkcl!> has joined #libre-soc22:29

Generated by 2.17.1 by Marius Gedminas - find it at!