| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 05:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:28 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 08:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:36 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 09:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.26> has joined #libre-soc | 09:04 | |
| *** irc <irc!~irc@46.23.94.12> has joined #libre-soc | 09:20 | |
| *** irc is now known as josuah | 10:24 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 10:50 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 11:09 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 11:24 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 12:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.26> has quit IRC | 12:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.149> has joined #libre-soc | 12:59 | |
| lkcl | markos, mornin (ish). it took me a day+ to work out what i have been subconsciously freaking out about. (this retrospective delay is a recurring 30+ year thing for me) | 13:00 |
|---|---|---|
| lkcl | it's nothing that was raised or discussed prior (not even remotely) | 13:00 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.149> has quit IRC | 13:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:34 | |
| lkcl | now, what's really interesting is: it's something that affects all of us. | 14:03 |
| lkcl | there is a solution: it involves NLnet, but the risk is we end up overloading NLnet and/or it violates NLnet's funding conditions | 14:04 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:13 | |
| markos | lkcl, you mention the solution, but I haven't understood the problem yet :) | 14:15 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:23 | |
| ghostmansd | lkcl, about https://libre-soc.org/irclog/%23libre-soc.2023-01-10.log.html#t2023-01-10T20:02:53 | 14:54 |
| ghostmansd | It seems you misunderstand the question | 14:54 |
| ghostmansd | Or, rather, I formulate it badly | 14:55 |
| ghostmansd | Considering this statement: `sv.crand/ff=eq/m=r10 12,2,33`... | 14:56 |
| ghostmansd | Given 32-bit prefix, what are the bits to be reflected in assembly by `=eq` value? | 14:57 |
| ghostmansd | And is it possible to have `sv.crand/ff=RC1/m=r10 12,2,33`? Seems like not, but there is RC1 field in https://libre-soc.org/openpower/sv/cr_ops/. | 14:57 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:59 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:59 | |
| ghostmansd | Considering this statement: `sv.crand/ff=eq/m=r10 12,2,33`... | 14:59 |
| ghostmansd | Given 32-bit prefix, what are the bits to be reflected in assembly by `=eq` value? | 14:59 |
| ghostmansd | And is it possible to have `sv.crand/ff=RC1/m=r10 12,2,33`? Seems like not, but there is RC1 field in https://libre-soc.org/openpower/sv/cr_ops/. | 14:59 |
| ghostmansd | Sorry for double-posting, IRC is quite unstable (in fact, compared to virtually anything, barely usable) | 15:10 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:21 | |
| ghostmansd | Also, this `sv.cmp/dz/ff=RC1/m=r3/sz *4,1,*0,1` seems to be an impossible combo: | 15:25 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=refs/heads/master#l1456 | 15:25 |
| ghostmansd | Ah wait, that's for pr= | 15:26 |
| ghostmansd | Here's for ff=: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=refs/heads/master#l1416 | 15:26 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:37 | |
| ghostmansd | `sv.extsw/dm=eq/sm=gt 3,7` does not look like a valid combination either: it's a twin predicate, P2/2P, and predicates should be the same. | 15:39 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:22 | |
| ghostmansd | programmerjake, could you remind me, please, what's the URL for our CI? I'd like to check insndb branch. | 16:28 |
| programmerjake | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/tree/add-insndb-to-gitlab-ci you never merged that branch so insndb ci doesn't cover insndb=true | 16:43 |
| programmerjake | my server was offline for a while, so maybe it failed git sync too many times and i need to restart it? | 16:45 |
| programmerjake | installing updates then i'll reboot it | 16:55 |
| ghostmansd[m] | Ah yes, perhaps all tests there will need one environment variable set as well... | 16:59 |
| ghostmansd[m] | On master, this variable is a no-op, though. | 16:59 |
| ghostmansd[m] | So perhaps this can be set globally. | 16:59 |
| programmerjake | i was expecting you to merge that branch into the insndb branch, since it has the ci changes needed to run insndb tests... | 17:00 |
| programmerjake | if the command isn't right anymore, feel free to change .gitlab-ci.yml as needed | 17:01 |
| programmerjake | rebooting, it was up for 114 days... | 17:02 |
| ghostmansd[m] | Ah, OK, I totally forgot about it | 17:13 |
| ghostmansd[m] | It's been a while :-) | 17:13 |
| ghostmansd[m] | I'll merge it soon | 17:13 |
| programmerjake | hmm, maybe git sync was working correctly before i rebooted, it ran ci on your latest commits 1hr ago... | 17:16 |
| programmerjake | gitlab's interface shows that commit as 3 weeks old tho... | 17:17 |
| ghostmansd | ah yeah, I entered the changes as fixup | 17:25 |
| ghostmansd | I don't bother about dates before merge | 17:26 |
| ghostmansd | programmerjake, I've cherry-picked that commit, and pushed the branch. Should I just wait for the latest insndb-branch-related job at https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/pipelines? | 17:34 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:36 | |
| programmerjake | yes, ci for that commit is at https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3797305 | 17:54 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.243> has joined #libre-soc | 18:01 | |
| programmerjake | test failures at https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3797305#L6620 | 18:03 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.243> has quit IRC | 18:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:14 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 18:43 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 18:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:49 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 20:19 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 20:19 | |
| programmerjake | maybe a little off-topic, but there's an interesting video about evga breaking overclocking world records with their cancelled rtx 4090, including flaming video cards and reballing the gpu: https://youtu.be/Gc0YlQS3Rx4 | 20:36 |
| lkcl | ghostmansd, ok, right. there *aren't* any 3 bits, on crand / cror (etc) | 21:08 |
| lkcl | it is a "5-bit mode" | 21:09 |
| lkcl | therefore if you specify "ff=eq" - if this syntax is even allowed - then it *absolutely has* to match the 2 bits from the BT result field | 21:09 |
| lkcl | the *only* bit that is "allowed" is the "inv" bit. | 21:10 |
| lkcl | so let us say that from the 5-bits of BT, there are 3 bits to specify "please use CR4" | 21:10 |
| lkcl | and the two remaining bits (LSBs) specify the "eq" filed of CR4 - CR4.eq - | 21:10 |
| lkcl | then you can ONLY | 21:10 |
| lkcl | repeat ***ONLY*** | 21:10 |
| lkcl | set "sv.crand/ff=eq" | 21:11 |
| lkcl | OR | 21:11 |
| lkcl | you can set "sv.crand/ff=ne" | 21:11 |
| lkcl | you CANNOT and MUST NOT do - allow - ANYTHING else | 21:11 |
| lkcl | now, the question becomes: should that syntax even be allowed, on operations with 5-bit CR result fields? | 21:12 |
| lkcl | or | 21:12 |
| lkcl | should instead a new specifier be added, let us say.... "/inv" | 21:12 |
| lkcl | i am leaning towards not adding a new specifier | 21:13 |
| lkcl | but instead having a syntax check on "/ff={whatever}" | 21:13 |
| lkcl | to make absolutely certain that the 2-bits specified by "/ff=xxxx" match 100% with the 2 LSBs of the 5-bit CR result | 21:13 |
| lkcl | and to throw a binutils (and pysvp64asm) syntax error if they do not. | 21:14 |
| ghostmansd | So we only consider inv part of the predicate? | 21:15 |
| ghostmansd | Considering eq == 0b100. What exactly goes to what exact bit of RM, if we assemble "sv.crand/ff=eq"? | 21:17 |
| lkcl | one bit and one bit only goes to RM: the "inv" bit | 21:17 |
| ghostmansd | IIRC 0b100 & 0b1 == inv | 21:17 |
| lkcl | https://libre-soc.org/openpower/sv/cr_ops/ | 21:17 |
| lkcl | /SNZ1 VLIinvdz szFfirst 5-bit mode (implies CR-bit from result) | 21:18 |
| lkcl | inv == bit 21 | 21:18 |
| ghostmansd | OK, so for CR ops that's mode[2] | 21:18 |
| lkcl | yes i believe so. been a while, now. | 21:18 |
| ghostmansd | Because CR ops reuse parts of mode | 21:18 |
| lkcl | yes. | 21:18 |
| ghostmansd | OK. What about RC1/~RC1? | 21:18 |
| lkcl | and that's what has to be syntax-checked | 21:18 |
| lkcl | it doesn't exist | 21:19 |
| ghostmansd | We will set inv too for ~RC1 | 21:19 |
| ghostmansd | But why on Earth is the field called RC1? | 21:19 |
| lkcl | no - there is no RC1 mode for cr_ops, as i explained last time | 21:19 |
| ghostmansd | There's field for power_insn, that's the one I'm talking about | 21:19 |
| ghostmansd | 1 sec | 21:19 |
| lkcl | there is no mention of "RC1" anywhere in this page https://libre-soc.org/openpower/sv/cr_ops/ | 21:19 |
| lkcl | and that's the specification. | 21:19 |
| lkcl | the specification is the specification, and the specification is canonical | 21:20 |
| ghostmansd | This is cool. Again, why did you add a field which clearly doesn't follow the specs? | 21:20 |
| lkcl | i.e. if you are seeing - anywhere - in any source code - "RC1" associated with cr_ops, then it is wrong | 21:20 |
| ghostmansd | I see a "cheat" comment | 21:20 |
| ghostmansd | But unable to trace the logic | 21:21 |
| lkcl | because i made a mistake, and it took about... 18 months to identify | 21:21 |
| lkcl | because i was focussed on arithmetic/logical first | 21:21 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=4aa2fff95f8b8ac88762f6b1be58f5b1e0780e9e;hb=refs/heads/master#l1796 | 21:21 |
| lkcl | then ld/st second | 21:21 |
| ghostmansd | No-no, this is a new code | 21:21 |
| ghostmansd | Quite fresh | 21:21 |
| lkcl | then only began to implement cr_ops only about 2-ish months ago | 21:21 |
| lkcl | *at which point* i *only then* began re-reading the specification | 21:22 |
| lkcl | and found mistakes | 21:22 |
| lkcl | which get corrected *in the specification first* | 21:22 |
| ghostmansd | So this RC1 for CR ops is something intermediate and should be dropped? | 21:22 |
| lkcl | because it is the specification that is the specification and takes absolute top priority and precedence over all and anything else | 21:22 |
| ghostmansd | And we have only real predicates? | 21:22 |
| ghostmansd | Luke, please stop repeating that. We both know you missed parts of the spec. | 21:23 |
| ghostmansd | I mean, before. | 21:23 |
| lkcl | again, you are confusing predicates with things | 21:23 |
| ghostmansd | My point is to clarify. | 21:23 |
| lkcl | RC1 has nothing to do with predicates | 21:23 |
| ghostmansd | I mean predicates like eq/lt/etc | 21:23 |
| ghostmansd | And RC1 is a different beast | 21:23 |
| lkcl | it's really important not to call them predicates | 21:23 |
| lkcl | because "sm=NN" is a predicate | 21:23 |
| * lkcl thinks.. | 21:24 | |
| lkcl | "/dm=NN" is a predicate | 21:24 |
| lkcl | but "/ff=NN" is *not* a predicate | 21:24 |
| lkcl | and neither is "RC1" | 21:24 |
| lkcl | what can we call them... | 21:24 |
| lkcl | any suggestions? | 21:24 |
| ghostmansd | No idea | 21:24 |
| ghostmansd | For now they are called predicates in insndb branch | 21:24 |
| lkcl | CR-bit-selectors? (clumsy) | 21:24 |
| ghostmansd | 1 sec | 21:25 |
| lkcl | ah i know: i have used "BO-selectors" before now | 21:25 |
| programmerjake | ff=NN -- NN is inv?-cr-bit | 21:25 |
| lkcl | because actually they are identical to Branch bits BO0 thru BO2 | 21:25 |
| lkcl | BO[0], BO[1], BO[2] | 21:25 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=bf97b7c721d66572ec41430f4ed01158c3fb499d;hb=refs/heads/insndb#l291 | 21:26 |
| lkcl | they do literally exactly the same thing, and should even be in the same order as the branch-conditional bits from the BO field | 21:26 |
| ghostmansd | Starting from here I made some enums | 21:26 |
| ghostmansd | Better names are welcome | 21:26 |
| lkcl | RC1=3 needs to be removed | 21:26 |
| lkcl | it cannot and will never be directly associated with predicates | 21:27 |
| lkcl | RC1 and ~RC1 if anything should be their own separate Enum class | 21:27 |
| lkcl | NONE | 21:27 |
| lkcl | RC1 | 21:27 |
| lkcl | RC1_INV | 21:27 |
| lkcl | something like that | 21:27 |
| lkcl | 404 @unique | 21:28 |
| lkcl | 405 class SVP64PredRC1(Enum): | 21:28 |
| lkcl | 406 RC1 = 0 | 21:28 |
| lkcl | 407 RC1_N = 1 | 21:28 |
| lkcl | ah. | 21:28 |
| lkcl | perfect. | 21:28 |
| ghostmansd | Please scroll below | 21:28 |
| lkcl | like that. | 21:28 |
| lkcl | 290 @unique | 21:28 |
| lkcl | 291 class SVP64PredMode(Enum): | 21:28 |
| lkcl | 292 ALWAYS = 0 | 21:28 |
| lkcl | 293 INT = 1 | 21:28 |
| lkcl | 294 CR = 2 | 21:28 |
| lkcl | 295 RC1 = 3 | 21:28 |
| lkcl | line 295 must be removed. | 21:28 |
| ghostmansd | SVP64PredMode.RC1... I don't remember why I added it. Perhaps I stored some table somewhere. | 21:28 |
| ghostmansd | Which has all this stuff which has inv and bits | 21:29 |
| lkcl | 451 RC1 = SVP64PredRC1.RC1 | 21:29 |
| lkcl | 452 RC1_N = SVP64PredRC1.RC1_N | 21:29 |
| ghostmansd | return super().match(desc=desc, record=record, | 21:29 |
| ghostmansd | mode_match=lambda mode_arg: mode_arg == mode, | 21:29 |
| ghostmansd | pred_match=lambda pred_arg: pred_arg.mode in ( | 21:29 |
| ghostmansd | _SVP64PredMode.CR, | 21:29 |
| ghostmansd | _SVP64PredMode.RC1, | 21:29 |
| ghostmansd | )) | 21:29 |
| lkcl | those two lines need to be removed | 21:29 |
| ghostmansd | That's the reason: I groupped them to check which arguments are accepted | 21:30 |
| lkcl | i think... | 21:30 |
| ghostmansd | that's for ff and pr | 21:30 |
| lkcl | 432 class SVP64Pred(Enum): | 21:30 |
| ghostmansd | ff or pr accept either "CR" or "RC1" -typed | 21:30 |
| lkcl | that should not be called "SVP64Pred" if it accepts ff and pr | 21:30 |
| lkcl | if however it is *actually* SVP64Pred, then lines 451 and 452 must be removed | 21:31 |
| ghostmansd | SVP64Pred is kinda umbrella for everything -- INT, CR and RC1 | 21:31 |
| ghostmansd | Just a way to construct any of these | 21:32 |
| lkcl | yyeah hence the confusion | 21:32 |
| ghostmansd | Kinda wrapper for "anything which belongs to INT/CR/RC1" | 21:32 |
| lkcl | and calling RC1 "a predicate" when it's confused with "a predicate mask" | 21:32 |
| ghostmansd | I think it's the naming that must be changed | 21:32 |
| * lkcl tck tck tck *thinks*... | 21:32 | |
| lkcl | ah, i know - they need to be separated | 21:33 |
| lkcl | to totally separate classes | 21:33 |
| ghostmansd | They kinda already are | 21:33 |
| lkcl | where "the-one-which-does ff and pr" would have duplicate LT/GE/GT etc | 21:33 |
| lkcl | and would happen to have RC1 and RC_N | 21:33 |
| ghostmansd | 433 ALWAYS = SVP64PredInt.ALWAYS | 21:33 |
| ghostmansd | 451 RC1 = SVP64PredRC1.RC1 | 21:34 |
| lkcl | but would NOT have R3, R10, etc. | 21:34 |
| lkcl | you absolutely cannot have "ff=r3" for example | 21:34 |
| ghostmansd | Yes, and this is checked | 21:34 |
| ghostmansd | class SpecifierFFPR(SpecifierPredicate): | 21:34 |
| ghostmansd | @classmethod | 21:34 |
| ghostmansd | def match(cls, desc, record, mode): | 21:34 |
| ghostmansd | return super().match(desc=desc, record=record, | 21:34 |
| ghostmansd | mode_match=lambda mode_arg: mode_arg == mode, | 21:34 |
| ghostmansd | pred_match=lambda pred_arg: pred_arg.mode in ( | 21:34 |
| ghostmansd | _SVP64PredMode.CR, | 21:34 |
| ghostmansd | _SVP64PredMode.RC1, | 21:34 |
| ghostmansd | )) | 21:34 |
| ghostmansd | Again, this is just a misnomer | 21:35 |
| lkcl | could you separate it to a totally different enum? | 21:35 |
| ghostmansd | 433 ALWAYS = SVP64PredInt.ALWAYS | 21:35 |
| lkcl | aiyaaa barometic pressure change, intense pain | 21:35 |
| ghostmansd | Don't you see the RHS? | 21:36 |
| lkcl | i have to go, i am in freaking serious pain | 21:36 |
| ghostmansd | there's a separate class for all of them | 21:36 |
| lkcl | i can't even concentrate on the keyboard let alone what you're putting in front of me | 21:36 |
| lkcl | gtg. NOW. | 21:36 |
| ghostmansd | bb | 21:36 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22:05 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 22:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 23:30 | |
| openpowerbot | [mattermost] <lkcl> ghostmansd, sorry about that - holy cow that was unbelievably painful. weather front incoming, changed barometric pressure and my sinuses are so shot to hell i couldn't stand the pain it was causing | 23:32 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 23:57 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!