| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 00:03 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 02:47 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 03:00 | |
| programmerjake | lkcl: 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 |
|---|---|---|
| programmerjake | for https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=806cd6e0f2239ee12aef3d2ee96cf2a14a54d13b | 06:35 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:39 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.25> has joined #libre-soc | 08: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 https://libre-soc.org/openpower/transcendentals/, 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-soc | 09:04 | |
| lkcl | programmerjake, yep good call | 10:17 |
| lkcl | 899 all the ops _were_ correctly numbered or so i thought but actually they aren't. they need renumbering. sigh. hence the opcode tables | 10:18 |
| lkcl | 899: none until they can be confirmed as non-conflicting. | 10:18 |
| lkcl | yes 911's the obvious one, it's just one instruction. | 10:19 |
| lkcl | programmerjake, 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 spec | 10:22 |
| lkcl | the mathematical symbols need reverting - they're not working out. | 10:24 |
| lkcl | or - some of them are, some of them aren't | 10:25 |
| lkcl | don'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 linebreak | 10:27 |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 11:44 | |
| *** yambo <yambo!~yambo@184.166.146.205> has joined #libre-soc | 11:49 | |
| *** octavius <octavius!~octavius@146.90.27.32> has joined #libre-soc | 11:51 | |
| lkcl | programmerjake, please stop wasting my time by continually using f"" strings | 12:15 |
| lkcl | they're fucking irritating because they're basically PHP, one of the worst languages ever written | 12:15 |
| programmerjake | imho the backslash looks terrible on ikiwiki, i'll be removing it if i can find something that works on ikiwiki and the pdf | 12:18 |
| lkcl | the PDF is the priority. | 12:18 |
| lkcl | but please: please acknowledge that you will cease adding f"" strings to code | 12:19 |
| lkcl | i am getting really fed up of wasting my time removing them constantly. | 12:19 |
| lkcl | it is making me really angry | 12:19 |
| lkcl | i have enough to deal with and because of RSI the less i have to type the less pain i have to endure | 12:20 |
| programmerjake | if 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 order | 12:20 |
| lkcl | tough | 12:21 |
| lkcl | get used to it. | 12:21 |
| lkcl | there's cases where it's useful, when there are multiple occurrences | 12:21 |
| lkcl | but as a "everything MUST be f"" because of one thing" it's just really irritating for me | 12:22 |
| programmerjake | e.g. f"a={a} b={b} c={c}" is better imho than "a=%s b=%d c=%g" % (a, b, c) | 12:22 |
| lkcl | i'm used to c. | 12:22 |
| lkcl | tough | 12:22 |
| lkcl | if 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 |
| lkcl | PHP - which is where this "feature" comes from - was a hard-knocks lesson for me | 12:23 |
| lkcl | i witnessed for over a decade how badly that went. | 12:23 |
| programmerjake | well, js has ` templates...c++ has "a=" << a << " b=" << b << " c=" << c | 12:23 |
| lkcl | fucking hell yet another one i have to waste my time on | 12:24 |
| programmerjake | rust added variable substitution to format strings but required them to *only* be variables, no expressions allowed (though that could change) | 12:25 |
| lkcl | i don't give a damn what rust does | 12:25 |
| lkcl | ISACaller is extremely complex | 12:26 |
| lkcl | it's a multi-faceted Finite State Machine that if not done carefully actually causes /usr/bin/python3.7 to segfault | 12:26 |
| lkcl | i 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 implementation | 12:27 |
| programmerjake | isacaller 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 languages | 12:27 |
| * sadoon[m] just wants to build the toolchain on p9 and has no idea what f""""""" is | 12:30 | |
| programmerjake | imho they added new features for a good reason, they should be used where appropriate...f"{this + long * and_('complex'.join(function_call()))}" is probably not | 12:30 |
| lkcl | sadoon[m], if you've ever seen PHP <? variablename ?> or "<html> <br > <? some_function_calling_something(with_varnames) ?>" | 12:31 |
| lkcl | then that's what format-strings are | 12:31 |
| programmerjake | sadoon: https://peps.python.org/pep-0498/ | 12:31 |
| sadoon[m] | Thankfully I've never used PHP in my life | 12:32 |
| sadoon[m] | :) | 12:32 |
| programmerjake | uuh, iirc php <? ?> is waay more general...you can put full code blocks in it, f"" strings are intended to be a small expression | 12:33 |
| programmerjake | f"" strings are basically shorthand for str.format | 12:35 |
| lkcl | frickin ellfire, parallel-reduce exceeds the total number of elements set by VL | 12:39 |
| sadoon[m] | is it normal for cvc5 to fail building? | 12:40 |
| lkcl | git clone -b cvc5-1.0.1 https://github.com/cvc5/cvc5.git cvc5 | 12:40 |
| lkcl | no | 12: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 that | 12:40 |
| lkcl | that's a specific tag | 12:40 |
| sadoon[m] | that's the line in the script, weird | 12:41 |
| sadoon[m] | I'll test again on x86 to see if it's ppc64le specific | 12:41 |
| lkcl | you may be running into... yes. | 12:41 |
| lkcl | it would not surprise me at all, unfortunately. | 12:41 |
| programmerjake | which script did you use to build cvc5? and on which arch? iirc i already solved building on ppc64le | 12:41 |
| lkcl | try cvc4 if cvc5 really doesn't work | 12:41 |
| sadoon[m] | ./hdl-tools-yosys | 12:42 |
| programmerjake | cvc4 doesn't have all the features of cvc5... | 12:42 |
| lkcl | programmerjake, everybody is instructed to use the dev-env-setup scripts so that there is no hassle. | 12:42 |
| lkcl | you are the only person that refuses to use or help maintain them | 12:42 |
| programmerjake | yeah, i know, but not everyone uses them exactly as instructed... | 12:43 |
| lkcl | no, they try to bypass them | 12:43 |
| lkcl | by typing out commands manually. | 12:43 |
| lkcl | it's a regular consistent pattern of behaviour and we just have to let them go through the pain | 12:44 |
| lkcl | damnit fricking parallel-reduction | 12: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 |
| programmerjake | last commit to hdl-tools-yosys is specifically making ppc64le work: https://git.libre-soc.org/?p=dev-env-setup.git;a=commitdiff;h=c36f889940a312771b844e89865c7ef009f5e5de | 12:44 |
| lkcl | the number of elements to be reduced is in no way the number of *operations* to be performed | 12:45 |
| programmerjake | lemme write a parallel reduction algorithm without moves or exceeding VL... | 12:45 |
| lkcl | no please do not do that | 12:46 |
| lkcl | i have already done it | 12:46 |
| lkcl | i prepared this many weeks ago. | 12:46 |
| programmerjake | uuh, but yours exceeds VL and makes it hard to find the destination element of the reduction... | 12:47 |
| lkcl | you've misunderstood | 12:47 |
| programmerjake | both of those are imho *bad* problems | 12:47 |
| lkcl | there is an *internal* loop needed which enumerates the total number of operations needed | 12:47 |
| lkcl | that requires a limit in order to know when to stop | 12:47 |
| lkcl | and there is the length of the vector being reduced | 12:47 |
| lkcl | these are *completely different* limits | 12:48 |
| lkcl | Matrix REMAP gets round the problem by being "in control" of setting VL | 12:48 |
| lkcl | you call svshape with the size of the matrices | 12:48 |
| lkcl | it computes the *total number of operations* needed and sets VL and MAXVL accordingly | 12:48 |
| lkcl | this trick cannot be done, here | 12:49 |
| lkcl | fricking frick | 12:49 |
| lkcl | all the loops in the entirety of ISACaller use for srcstep/dststep in range(VL) | 12:49 |
| lkcl | and that now has to be | 12:50 |
| programmerjake | ah, 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 <= 1 | 12:50 |
| lkcl | for srcstep/dststep in range(COMPUTED_PARALLEL_PREFIX_TOTAL(VL)) | 12:50 |
| lkcl | no | 12:50 |
| lkcl | please do *not* interfer | 12:50 |
| lkcl | i have *already written* the algorithm | 12:50 |
| lkcl | please do *not* interfere. | 12:51 |
| programmerjake | lemme try, it's *better* than any of the previously proposed algorithms by either you or i | 12:51 |
| lkcl | no. | 12:51 |
| lkcl | please do *not* interfere | 12:51 |
| lkcl | you can help by reviewing the algorithm written | 12:51 |
| lkcl | you can help by providing suggestions | 12:51 |
| lkcl | but please *do not* interfere | 12:51 |
| lkcl | you have enough to do on the transcendentals | 12:51 |
| lkcl | we only have 4 weeks left | 12:52 |
| lkcl | please do *not* interfere | 12:52 |
| lkcl | have you got the message yet | 12:52 |
| lkcl | please *do not* interfere | 12:52 |
| lkcl | please acknowledge that you will not interfere | 12:52 |
| programmerjake | it would take me 1hr to write...i can afford to take that long of a break imho... | 12:52 |
| lkcl | no | 12:52 |
| lkcl | i have said no eight times now | 12:52 |
| lkcl | and requested that you do not interfere | 12:52 |
| programmerjake | i'm taking a much longer break anyway to fix my car... | 12:52 |
| lkcl | please acknowledge - for the 9th time - that you will not interfere | 12:53 |
| lkcl | please acknowledge - for the 10th time - that you will leave this task to me to complete | 12:53 |
| lkcl | please acknowledge - for the 11th time - that you will leave this task to me | 12:54 |
| lkcl | please acknowledge - for the 12th time - that you will leave this task to me | 12:54 |
| programmerjake | go ahead, but i'm still proposing that algorithm...lkcl you don't need to repeat yourself incessantly | 12:54 |
| lkcl | then please acknowledge earlier | 12:54 |
| lkcl | i am really deeply stressed that you don't acknowledge and keep pushing | 12:55 |
| lkcl | you know this but keep doing it | 12:55 |
| programmerjake | you gave me little chance because you were too busy spamming chat with "don't interfere", i need time to type/think | 12:55 |
| lkcl | i need to think through how to solve this one myself. | 12:55 |
| lkcl | in one of the most complex and critical areas on which the entire project depends i need to know *exactly* what is going on | 12:56 |
| lkcl | and right now i've just realised that there's a fundamental mistake | 12:57 |
| programmerjake | k, go ahead but we may need to later alter the code your writing now if/when we change the spec to be better | 12:57 |
| lkcl | and you're offering to wade in | 12:57 |
| lkcl | decoupling srcstep/dststep limit-checks from VL hits the code in dozens of places | 12:58 |
| lkcl | no "algorithm" will fix that | 12:58 |
| lkcl | it's a fundamental fuck-up on my part | 12:58 |
| lkcl | so i need to think it through, carefully. | 12:58 |
| programmerjake | the new spec algorithm doesn't need src/deststep to exceed VL, since it uses the predicate mask to track state | 12:59 |
| programmerjake | lemme write it out and see what you think...note i thought of it a few days ago, not just right now when you encountered trouble | 13:00 |
| lkcl | NO. please LISTEN | 13:01 |
| lkcl | this 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 |
| lkcl | taken out of all Modes and only activated via REMAP | 13:02 |
| lkcl | where svshape can be told, like Matrix, what the length is, and it can decide to set MVL/VL. | 13:03 |
| programmerjake | i'm listening, but imho you need to see the new algorithm, it doesn't need remap at all... | 13:03 |
| lkcl | that has the side-benefit of stopping the (very complex) double-application of REMAP *on top* of pprefix | 13:03 |
| lkcl | preduce | 13:03 |
| lkcl | which has the important side-benefit of reducing gate-latency in hardware | 13:04 |
| lkcl | what a fuckup. with only four weeks to funding-cutoff deadline. | 13:05 |
| programmerjake | if you see the new algorithm it could fix all our current issues with the remap-based tree reduce | 13:06 |
| lkcl | ghostmansd[m], putting parallel-reduction into REMAP simplifies your job - it's less bits in the mode tables. | 13:53 |
| lkcl | i'll deal with the edits on the spec. | 13:53 |
| lkcl | programmerjake, which bit of "no" fifteen times was not clear? | 13:54 |
| lkcl | there is *not enough time* and the algorithm has already been written | 13:54 |
| programmerjake | well, 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 imho | 13:57 |
| programmerjake | i'd expect the isa wg to have issues with the reduction algo. because of the locating final result issue | 13:58 |
| lkcl | that's extremely easy to solve. first method perform a VREDUCE-mv | 15:04 |
| lkcl | second method follow up with a predicated vector-to-scalar mv (or use) | 15:05 |
| lkcl | if there were no operations performed then it was only because there was a single bit in the predicate | 15:05 |
| lkcl | in which case the result is in the original source vector in that exact single-bit position | 15:06 |
| lkcl | otherwise the result is *still* in the first bit-position of the predicate mask | 15:06 |
| programmerjake | my proposed algorithm solves all that, and more...it's 100% interruptible and restartable with only the predicate mask needed as state tracking | 15:08 |
| programmerjake | see email | 15:08 |
| programmerjake | sorry, didn't see you sent one till i sent mine, so it's a different thread | 15:08 |
| lkcl | SIXTEEN FUCKING TIMES I'VE SAID NO | 15:10 |
| lkcl | will you FUCKING WELL FUCKING LISTEN | 15:10 |
| lkcl | you are WASTING TIME when we are UNDER A DEADLINE | 15:10 |
| lkcl | please focus on the ALLOCATED TASKS | 15:11 |
| lkcl | i do NOT HAVE TIME to examine the algorithm that you have wasted your time writing | 15:11 |
| lkcl | i told you ****NO***** | 15:11 |
| lkcl | and you didn't fucking listen | 15:11 |
| lkcl | AGAIN | 15:11 |
| programmerjake | the new algorithm *saves time* because it fixes all the issues you ran into...please look at it | 15:12 |
| lkcl | FUCKING STOP | 15:12 |
| lkcl | NO | 15:12 |
| lkcl | that's SEVENTEEN TIMES i've said NO | 15:12 |
| lkcl | PLEASE STOP | 15:12 |
| lkcl | it is deeply disrespectful and distressing that you do not listen | 15:12 |
| lkcl | everyone 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 listening | 15:13 |
| lkcl | this is NOT YOUR TASK TO TACKLE | 15:13 |
| lkcl | i have said NO. | 15:13 |
| lkcl | EIGHTEEN times i have said NO. | 15:13 |
| lkcl | please GET THE FUCKING MESSAGE and FOCUS | 15:14 |
| lkcl | have you got the message now? | 15:14 |
| programmerjake | well, 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 |
| lkcl | you 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 pressure | 15:14 |
| lkcl | it is WASTING TIME | 15:14 |
| lkcl | you should not have spent the time writing it when it distracts from a deadline task! | 15:15 |
| lkcl | i told you NO. | 15:15 |
| lkcl | that's NINETEEN times i said no. | 15:15 |
| programmerjake | it's not wasted because i wouldn't have been working on libre-soc anyway at this hour, it's my day off | 15:15 |
| lkcl | don't get stroppy about this or feel "hurt", just learn and damn well stop wasting time | 15:16 |
| lkcl | you're wasting MY time | 15:16 |
| lkcl | and disrupting the project and deeply disturbing the other project members by demonstrating that you CANNOT LISTEN | 15:16 |
| programmerjake | k, sorry... | 15:16 |
| lkcl | ok. thank you | 15:16 |
| programmerjake | please do look at it later tho | 15:17 |
| programmerjake | like october | 15:17 |
| lkcl | remember - 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 |
| programmerjake | note that you're effectively ignoring what i've written, which is a form of not listening. i'm going to sleep now, ttyl | 15:22 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.25> has quit IRC | 16:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@185.79.101.99> has joined #libre-soc | 16:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@185.79.101.99> has quit IRC | 16:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.112> has joined #libre-soc | 16:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.112> has quit IRC | 18:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:26 | |
| *** tplaten <tplaten!~isengaara@55d462f2.access.ecotel.net> has joined #libre-soc | 18:29 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 19:16 | |
| *** tplaten <tplaten!~isengaara@55d462f2.access.ecotel.net> has quit IRC | 19:59 | |
| ghostmansd | Damn. 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@146.90.27.32> has quit IRC | 22:53 | |
| lkcl | openpower/isatables/minor_31.csv:0b0000010100,LDST,OP_LOAD,RA_OR_ZERO,RB, | 23:06 |
| lkcl | definitely there... | 23:06 |
| lkcl | ghostmansd, is this correct? (git diff follows) | 23:47 |
| lkcl | +++ b/src/openpower/decoder/power_insn.py | 23:47 |
| lkcl | @@ -487,7 +487,7 @@ class StaticOperand(Operand): | 23:47 |
| lkcl | class DynamicOperandTargetAddrLI(DynamicOperand): | 23:47 |
| lkcl | @property | 23: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 | @property | 23:47 |
| lkcl | def name(self): | 23:47 |
| lkcl | - return "BD" | 23:47 |
| lkcl | + return "target_addr" | 23:47 |
| lkcl | ? | 23:47 |
| lkcl | target_addr branch - https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=d657266ae0e4b6c034e67ec1797c24e59861b547 | 23:55 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!