Monday, 2022-09-05

*** choozy <choozy!> has quit IRC00:03
*** lkcl <lkcl!> has quit IRC02:47
*** lkcl <lkcl!> has joined #libre-soc03:00
programmerjakelkcl: rather than naming stuff `PARALLEL` for parallel tree reduction, imho a much better name would be `PTREDUCE` or `TREE_REDUCE`, since PARALLEL doesn't tell you *what's* parallel, just that something is parallel.06:34
*** ghostmansd <ghostmansd!> has quit IRC08:16
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:39
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc08:40
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:44
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:44
ghostmansd[m]lkcl, I've been thinking that perhaps I should switch a bit into other tasks, to avoid blurred eye due to constantly doing the same task. Candidates are 864, 871, 899, 911.08:52
ghostmansd[m]911 seems to be the most obvious choice, I understand what must be done there, plus I still owe another patch to binutils. I'll start with this one, but likely I'll be able to reach the laptop only in the evening.08:53
ghostmansd[m]899 needs some of these, but which are already "stabilized"? From the page it appears it's WiP.08:57
ghostmansd[m]That is, for 899, what are instructions that can already be added along with disasm tests?08:58
*** psydroid <psydroid!~psydroid@user/psydroid> has joined #libre-soc09:04
lkclprogrammerjake, yep good call10:17
lkcl899 all the ops _were_ correctly numbered or so i thought but actually they aren't. they need renumbering. sigh. hence the opcode tables10:18
lkcl899: none until they can be confirmed as non-conflicting.10:18
lkclyes 911's the obvious one, it's just one instruction.10:19
lkclprogrammerjake, do note the format changes i did (by hand) to get the PDF to render. that's important and you need to check it as part of any edits to the spec10:22
lkclthe mathematical symbols need reverting - they're not working out.10:24
lkclor - some of them are, some of them aren't10:25
lkcldon't remove the "backslash two spaces" voodoo-magic incantation in the table. it took an inordinate amount of time to find it as the method of gettign a linebreak10:27
*** yambo <yambo!~yambo@> has quit IRC11:44
*** yambo <yambo!~yambo@> has joined #libre-soc11:49
*** octavius <octavius!~octavius@> has joined #libre-soc11:51
lkclprogrammerjake, please stop wasting my time by continually using f"" strings12:15
lkclthey're fucking irritating because they're basically PHP, one of the worst languages ever written12:15
programmerjakeimho the backslash looks terrible on ikiwiki, i'll be removing it if i can find something that works on ikiwiki and the pdf12:18
lkclthe PDF is the priority.12:18
lkclbut please: please acknowledge that you will cease adding f"" strings to code12:19
lkcli am getting really fed up of wasting my time removing them constantly.12:19
lkclit is making me really angry12:19
lkcli have enough to deal with and because of RSI the less i have to type the less pain i have to endure12:20
programmerjakeif it's just variable substitution rather than a bunch of logic, imho f"" strings are *more* clear and understandable than something like % where you have to match order12:20
lkclget used to it.12:21
lkclthere's cases where it's useful, when there are multiple occurrences12:21
lkclbut as a "everything MUST be f"" because of one thing" it's just really irritating for me12:22
programmerjakee.g. f"a={a} b={b} c={c}" is better imho than "a=%s b=%d c=%g" % (a, b, c)12:22
lkcli'm used to c.12:22
lkclif that was repeated occurrences of a, b or c, as in a, b c c b a i'd be ok with it (reluctantly)12:23
lkclPHP - which is where this "feature" comes from - was a hard-knocks lesson for me12:23
lkcli witnessed for over a decade how badly that went.12:23
programmerjakewell, js has ` templates...c++ has "a=" << a << " b=" << b << " c=" << c12:23
lkclfucking hell yet another one i have to waste my time on12:24
programmerjakerust added variable substitution to format strings but required them to *only* be variables, no expressions allowed (though that could change)12:25
lkcli don't give a damn what rust does12:25
lkclISACaller is extremely complex12:26
lkclit's a multi-faceted Finite State Machine that if not done carefully actually causes /usr/bin/python3.7 to segfault12:26
lkcli don't need *any* hassle of use of "features" of languages that piss me off, distracting me from the real job of maintaining this fucking complex an implementation12:27
programmerjakeisacaller is complex -- don't make it worse by doing something terrible like log("my_a b c d e f g x y z", a, b, c, d, e, f, g, x, y, z)12:27
lkcl*please* don't try to sell me features of languages12:27
* sadoon[m] just wants to build the toolchain on p9 and has no idea what f""""""" is12:30
programmerjakeimho they added new features for a good reason, they should be used where appropriate...f"{this + long * and_('complex'.join(function_call()))}" is probably not12:30
lkclsadoon[m], if you've ever seen PHP  <? variablename ?> or  "<html> <br > <? some_function_calling_something(with_varnames) ?>"12:31
lkclthen that's what format-strings are12:31
sadoon[m]Thankfully I've never used PHP in my life12:32
programmerjakeuuh, iirc php <? ?> is waay more can put full code blocks in it, f"" strings are intended to be a small expression12:33
programmerjakef"" strings are basically shorthand for str.format12:35
lkclfrickin ellfire, parallel-reduce exceeds the total number of elements set by VL12:39
sadoon[m]is it normal for cvc5 to fail building?12:40
lkclgit clone -b cvc5-1.0.1 cvc512:40
sadoon[m]The scripts could use some better error reporting because if I hadn't noticed at the time of failure I would think all went well, I'll work on that12:40
lkclthat's a specific tag12:40
sadoon[m]that's the line in the script, weird12:41
sadoon[m]I'll test again on x86 to see if it's ppc64le specific12:41
lkclyou may be running into... yes.12:41
lkclit would not surprise me at all, unfortunately.12:41
programmerjakewhich script did you use to build cvc5? and on which arch? iirc i already solved building on ppc64le12:41
lkcltry cvc4 if cvc5 really doesn't work12:41
programmerjakecvc4 doesn't have all the features of cvc5...12:42
lkclprogrammerjake, everybody is instructed to use the dev-env-setup scripts so that there is no hassle.12:42
lkclyou are the only person that refuses to use or help maintain them12:42
programmerjakeyeah, i know, but not everyone uses them exactly as instructed...12:43
lkclno, they try to bypass them12:43
lkclby typing out commands manually.12:43
lkclit's a regular consistent pattern of behaviour and we just have to let them go through the pain12:44
lkcldamnit fricking parallel-reduction12:44
sadoon[m]argh I need to setup my 2960 in order to get internet on both p9 and x86, moving process troubles :)12:44
programmerjakelast commit to hdl-tools-yosys is specifically making ppc64le work:;a=commitdiff;h=c36f889940a312771b844e89865c7ef009f5e5de12:44
lkclthe number of elements to be reduced is in no way the number of *operations* to be performed12:45
programmerjakelemme write a parallel reduction algorithm without moves or exceeding VL...12:45
lkclno please do not do that12:46
lkcli have already done it12:46
lkcli prepared this many weeks ago.12:46
programmerjakeuuh, but yours exceeds VL and makes it hard to find the destination element of the reduction...12:47
lkclyou've misunderstood12:47
programmerjakeboth of those are imho *bad* problems12:47
lkclthere is an *internal* loop needed which enumerates the total number of operations needed12:47
lkclthat requires a limit in order to know when to stop12:47
lkcland there is the length of the vector being reduced12:47
lkclthese are *completely different* limits12:48
lkclMatrix REMAP gets round the problem by being "in control" of setting VL12:48
lkclyou call svshape with the size of the matrices12:48
lkclit computes the *total number of operations* needed and sets VL and MAXVL accordingly12:48
lkclthis trick cannot be done, here12:49
lkclfricking frick12:49
lkclall the loops in the entirety of ISACaller use for srcstep/dststep in range(VL)12:49
lkcland that now has to be12:50
programmerjakeah, yeah. well, let me rewrite the algorithm, i have an idea for modifying the predicate mask that solves that problem without needing to modify remap, it should work with the existing isacaller loop with a tiny modification to jump to self if the popcount of the mask isn't <= 112:50
lkclfor srcstep/dststep in range(COMPUTED_PARALLEL_PREFIX_TOTAL(VL))12:50
lkclplease do *not* interfer12:50
lkcli have *already written* the algorithm12:50
lkclplease do *not* interfere.12:51
programmerjakelemme try, it's *better* than any of the previously proposed algorithms by either you or i12:51
lkclplease do *not* interfere12:51
lkclyou can help by reviewing the algorithm written12:51
lkclyou can help by providing suggestions12:51
lkclbut please *do not* interfere12:51
lkclyou have enough to do on the transcendentals12:51
lkclwe only have 4 weeks left12:52
lkclplease do *not* interfere12:52
lkclhave you got the message yet12:52
lkclplease *do not* interfere12:52
lkclplease acknowledge that you will not interfere12:52
programmerjakeit would take me 1hr to write...i can afford to take that long of a break imho...12:52
lkcli have said no eight times now12:52
lkcland requested that you do not interfere12:52
programmerjakei'm taking a much longer break anyway to fix my car...12:52
lkclplease acknowledge - for the 9th time - that you will not interfere12:53
lkclplease acknowledge - for the 10th time - that you will leave this task to me to complete12:53
lkclplease acknowledge - for the 11th time - that you will leave this task to me12:54
lkclplease acknowledge - for the 12th time - that you will leave this task to me12:54
programmerjakego ahead, but i'm still proposing that algorithm...lkcl you don't need to repeat yourself incessantly12:54
lkclthen please acknowledge earlier12:54
lkcli am really deeply stressed that you don't acknowledge and keep pushing12:55
lkclyou know this but keep doing it12:55
programmerjakeyou gave me little chance because you were too busy spamming chat with "don't interfere", i need time to type/think12:55
lkcli need to think through how to solve this one myself.12:55
lkclin one of the most complex and critical areas on which the entire project depends i need to know *exactly* what is going on12:56
lkcland right now i've just realised that there's a fundamental mistake12:57
programmerjakek, go ahead but we may need to later alter the code your writing now if/when we change the spec to be better12:57
lkcland you're offering to wade in12:57
lkcldecoupling srcstep/dststep limit-checks from VL hits the code in dozens of places12:58
lkclno "algorithm" will fix that12:58
lkclit's a fundamental fuck-up on my part12:58
lkclso i need to think it through, carefully.12:58
programmerjakethe new spec algorithm doesn't need src/deststep to exceed VL, since it uses the predicate mask to track state12:59
programmerjakelemme write it out and see what you think...note i thought of it a few days ago, not just right now when you encountered trouble13:00
lkclNO. please LISTEN13:01
lkclthis is really fundamental.  my current feeling is that this is so badly f****d up that parallel-reduction has to become a REMAP.13:02
lkcltaken out of all Modes and only activated via REMAP13:02
lkclwhere svshape can be told, like Matrix, what the length is, and it can decide to set MVL/VL.13:03
programmerjakei'm listening, but imho you need to see the new algorithm, it doesn't need remap at all...13:03
lkclthat has the side-benefit of stopping the (very complex) double-application of REMAP *on top* of pprefix13:03
lkclwhich has the important side-benefit of reducing gate-latency in hardware13:04
lkclwhat a fuckup.  with only four weeks to funding-cutoff deadline.13:05
programmerjakeif you see the new algorithm it could fix all our current issues with the remap-based tree reduce13:06
lkclghostmansd[m], putting parallel-reduction into REMAP simplifies your job - it's less bits in the mode tables.13:53
lkcli'll deal with the edits on the spec.13:53
lkclprogrammerjake, which bit of "no" fifteen times was not clear?13:54
lkclthere is *not enough time* and the algorithm has already been written13:54
programmerjakewell, our current algorithm is terrible because it makes it really difficult to locate the final result and because it has double-nested-remap, and no matter how short an amount of time you want, terribleness should be fixed imho13:57
programmerjakei'd expect the isa wg to have issues with the reduction algo. because of the locating final result issue13:58
lkclthat's extremely easy to solve.  first method perform a VREDUCE-mv15:04
lkclsecond method follow up with a predicated vector-to-scalar mv (or use)15:05
lkclif there were no operations performed then it was only because there was a single bit in the predicate15:05
lkclin which case the result is in the original source vector in that exact single-bit position15:06
lkclotherwise the result is *still* in the first bit-position of the predicate mask15:06
programmerjakemy proposed algorithm solves all that, and's 100% interruptible and restartable with only the predicate mask needed as state tracking15:08
programmerjakesee email15:08
programmerjakesorry, didn't see you sent one till i sent mine, so it's a different thread15:08
lkclyou are WASTING TIME when we are UNDER A DEADLINE15:10
lkclplease focus on the ALLOCATED TASKS15:11
lkcli do NOT HAVE TIME to examine the algorithm that you have wasted your time writing15:11
lkcli told you ****NO*****15:11
lkcland you didn't fucking listen15:11
programmerjakethe new algorithm *saves time* because it fixes all the issues you ran into...please look at it15:12
lkclthat's SEVENTEEN TIMES i've said NO15:12
lkclPLEASE STOP15:12
lkclit is deeply disrespectful and distressing that you do not listen15:12
lkcleveryone here on this IRC channel who sees this - particularly right when i have just invited someone new to join - is going to be deeply embarrassed that you're not listening15:13
lkclthis is NOT YOUR TASK TO TACKLE15:13
lkcli have said NO.15:13
lkclEIGHTEEN times i have said NO.15:13
lkclhave you got the message now?15:14
programmerjakewell, then, go have fun building tree reduction as a remap mode, my new algorithm is waiting until you take the time to listen and imho it's better (maybe after october?). just cuz it's not the task assigned to me doesn't mean i can't have a better idea than any of what we had before...15:14
lkclyou should in absolutely no way cause me to have to waste time requesting EIGHTEEN times that you CEASE wasting time on something that is not your allocated task under deadline pressure15:14
lkclit is WASTING TIME15:14
lkclyou should not have spent the time writing it when it distracts from a deadline task!15:15
lkcli told you NO.15:15
lkclthat's NINETEEN times i said no.15:15
programmerjakeit's not wasted because i wouldn't have been working on libre-soc anyway at this hour, it's my day off15:15
lkcldon't get stroppy about this or feel "hurt", just learn and damn well stop wasting time15:16
lkclyou're wasting MY time15:16
lkcland disrupting the project and deeply disturbing the other project members by demonstrating that you CANNOT LISTEN15:16
programmerjakek, sorry...15:16
lkclok. thank you15:16
programmerjakeplease do look at it later tho15:17
programmerjakelike october15:17
lkclremember - please - i've been dealing for 12 years with a verbally-abusive partner (who has not been listening) and you're doing the same thing by not listening.15:18
programmerjakenote that you're effectively ignoring what i've written, which is a form of not listening. i'm going to sleep now, ttyl15:22
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:34
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:44
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:44
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:11
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:12
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC18:23
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:26
*** tplaten <tplaten!> has joined #libre-soc18:29
*** ghostmansd <ghostmansd!> has joined #libre-soc19:16
*** tplaten <tplaten!> has quit IRC19:59
ghostmansdDamn. Just found we failed upon finding opcode for lwarx instruction, so I guess we're not completed on opcodes. I'll check tomorrow.20:43
*** octavius <octavius!~octavius@> has quit IRC22:53
lkcldefinitely there...23:06
lkclghostmansd, is this correct? (git diff follows)23:47
lkcl+++ b/src/openpower/decoder/power_insn.py23:47
lkcl@@ -487,7 +487,7 @@ class StaticOperand(Operand):23:47
lkcl class DynamicOperandTargetAddrLI(DynamicOperand):23:47
lkcl     @property23:47
lkcl     def name(self):23:47
lkcl-        return "LI"23:47
lkcl+        return "target_addr"23:47
lkcl@@ -508,7 +508,7 @@ class DynamicOperandTargetAddrLI(DynamicOperand):23:47
lkcl class DynamicOperandTargetAddrBD(DynamicOperand):23:47
lkcl     @property23:47
lkcl     def name(self):23:47
lkcl-        return "BD"23:47
lkcl+        return "target_addr"23:47
lkcltarget_addr branch -;a=commitdiff;h=d657266ae0e4b6c034e67ec1797c24e59861b54723:55

Generated by 2.17.1 by Marius Gedminas - find it at!