Sunday, 2023-01-15

*** ghostmansd <ghostmansd!> has joined #libre-soc05:32
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC05:33
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc07:00
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:28
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc08:27
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:36
*** josuah <josuah!~irc@> has quit IRC09:04
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc09:04
*** irc <irc!~irc@> has joined #libre-soc09:20
*** irc is now known as josuah10:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC10:50
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc11:09
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC11:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc12:03
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC12:57
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:59
lkclmarkos, 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
lkclit's nothing that was raised or discussed prior (not even remotely)13:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:22
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc13:24
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:34
lkclnow, what's really interesting is: it's something that affects all of us.14:03
lkclthere is a solution: it involves NLnet, but the risk is we end up overloading NLnet and/or it violates NLnet's funding conditions14:04
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:13
markoslkcl, you mention the solution, but I haven't understood the problem yet :)14:15
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC14:23
ghostmansdlkcl, about
ghostmansdIt seems you misunderstand the question14:54
ghostmansdOr, rather, I formulate it badly14:55
ghostmansdConsidering this statement: `sv.crand/ff=eq/m=r10 12,2,33`...14:56
ghostmansdGiven 32-bit prefix, what are the bits to be reflected in assembly by `=eq` value?14:57
ghostmansdAnd is it possible to have `sv.crand/ff=RC1/m=r10 12,2,33`? Seems like not, but there is RC1 field in
*** ghostmansd <ghostmansd!> has quit IRC14:59
*** ghostmansd <ghostmansd!> has joined #libre-soc14:59
ghostmansdConsidering this statement: `sv.crand/ff=eq/m=r10 12,2,33`...14:59
ghostmansdGiven 32-bit prefix, what are the bits to be reflected in assembly by `=eq` value?14:59
ghostmansdAnd is it possible to have `sv.crand/ff=RC1/m=r10 12,2,33`? Seems like not, but there is RC1 field in
ghostmansdSorry for double-posting, IRC is quite unstable (in fact, compared to virtually anything, barely usable)15:10
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15:12
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:21
ghostmansdAlso, this `sv.cmp/dz/ff=RC1/m=r3/sz *4,1,*0,1` seems to be an impossible combo:15:25
ghostmansdAh wait, that's for pr=15:26
ghostmansdHere's for ff=:;a=blob;f=src/openpower/sv/trans/;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=refs/heads/master#l141615:26
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15: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]!> has quit IRC15:50
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc16:22
ghostmansdprogrammerjake, could you remind me, please, what's the URL for our CI? I'd like to check insndb branch.16:28
programmerjake you never merged that branch so insndb ci doesn't cover insndb=true16:43
programmerjakemy server was offline for a while, so maybe it failed git sync too many times and i need to restart it?16:45
programmerjakeinstalling updates then i'll reboot it16: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
programmerjakei was expecting you to merge that branch into the insndb branch, since it has the ci changes needed to run insndb tests...17:00
programmerjakeif the command isn't right anymore, feel free to change .gitlab-ci.yml as needed17:01
programmerjakerebooting, it was up for 114 days...17:02
ghostmansd[m]Ah, OK, I totally forgot about it17:13
ghostmansd[m]It's been a while :-)17:13
ghostmansd[m]I'll merge it soon17:13
programmerjakehmm, maybe git sync was working correctly before i rebooted, it ran ci on your latest commits 1hr ago...17:16
programmerjakegitlab's interface shows that commit as 3 weeks old tho...17:17
ghostmansdah yeah, I entered the changes as fixup17:25
ghostmansdI don't bother about dates before merge17:26
ghostmansdprogrammerjake, I've cherry-picked that commit, and pushed the branch. Should I just wait for the latest insndb-branch-related job at
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC17:36
programmerjakeyes, ci for that commit is at
*** ghostmansd <ghostmansd!> has quit IRC17:58
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc18:01
programmerjaketest failures at
*** ghostmansd <ghostmansd!> has joined #libre-soc18:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:12
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:14
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC18:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc18:44
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC18:49
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC20:19
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc20:19
programmerjakemaybe 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:
lkclghostmansd, ok, right.  there *aren't* any 3 bits, on crand / cror (etc)21:08
lkclit is a "5-bit mode"21:09
lkcltherefore if you specify "ff=eq" - if this syntax is even allowed - then it *absolutely has* to match the 2 bits from the BT result field21:09
lkclthe *only* bit that is "allowed" is the "inv" bit.21:10
lkclso let us say that from the 5-bits of BT, there are 3 bits to specify "please use CR4"21:10
lkcland the two remaining bits (LSBs) specify the "eq" filed of CR4 - CR4.eq -21:10
lkclthen you can ONLY21:10
lkclrepeat ***ONLY***21:10
lkclset "sv.crand/ff=eq"21:11
lkclyou can set "sv.crand/ff=ne"21:11
lkclyou CANNOT and MUST NOT do - allow - ANYTHING else21:11
lkclnow, the question becomes: should that syntax even be allowed, on operations with 5-bit CR result fields?21:12
lkclshould instead a new specifier be added, let us say.... "/inv"21:12
lkcli am leaning towards not adding a new specifier21:13
lkclbut instead having a syntax check on "/ff={whatever}"21:13
lkclto make absolutely certain that the 2-bits specified by "/ff=xxxx" match 100% with the 2 LSBs of the 5-bit CR result21:13
lkcland to throw a binutils (and pysvp64asm) syntax error if they do not.21:14
ghostmansdSo we only consider inv part of the predicate?21:15
ghostmansdConsidering eq == 0b100. What exactly goes to what exact bit of RM, if we assemble "sv.crand/ff=eq"?21:17
lkclone bit and one bit only goes to RM: the "inv" bit21:17
ghostmansdIIRC 0b100 & 0b1 == inv21:17
lkcl /SNZ1 VLIinvdz szFfirst 5-bit mode (implies CR-bit from result)21:18
lkclinv == bit 2121:18
ghostmansdOK, so for CR ops that's mode[2]21:18
lkclyes i believe so. been a while, now.21:18
ghostmansdBecause CR ops reuse parts of mode21:18
ghostmansdOK. What about RC1/~RC1?21:18
lkcland that's what has to be syntax-checked21:18
lkclit doesn't exist21:19
ghostmansdWe will set inv too for ~RC121:19
ghostmansdBut why on Earth is the field called RC1?21:19
lkclno - there is no RC1 mode for cr_ops, as i explained last time21:19
ghostmansdThere's field for power_insn, that's the one I'm talking about21:19
ghostmansd1 sec21:19
lkclthere is no mention of "RC1" anywhere in this page
lkcland that's the specification.21:19
lkclthe specification is the specification, and the specification is canonical21:20
ghostmansdThis is cool. Again, why did you add a field which clearly doesn't follow the specs?21:20
lkcli.e. if you are seeing - anywhere - in any source code - "RC1" associated with cr_ops, then it is wrong21:20
ghostmansdI see a "cheat" comment21:20
ghostmansdBut unable to trace the logic21:21
lkclbecause i made a mistake, and it took about... 18 months to identify21:21
lkclbecause i was focussed on arithmetic/logical first21:21
lkclthen ld/st second21:21
ghostmansdNo-no, this is a new code21:21
ghostmansdQuite fresh21:21
lkclthen only began to implement cr_ops only about 2-ish months ago21:21
lkcl*at which point* i *only then* began re-reading the specification21:22
lkcland found mistakes21:22
lkclwhich get corrected *in the specification first*21:22
ghostmansdSo this RC1 for CR ops is something intermediate and should be dropped?21:22
lkclbecause it is the specification that is the specification and takes absolute top priority and precedence over all and anything else21:22
ghostmansdAnd we have only real predicates?21:22
ghostmansdLuke, please stop repeating that. We both know you missed parts of the spec.21:23
ghostmansdI mean, before.21:23
lkclagain, you are confusing predicates with things21:23
ghostmansdMy point is to clarify.21:23
lkclRC1 has nothing to do with predicates21:23
ghostmansdI mean predicates like eq/lt/etc21:23
ghostmansdAnd RC1 is a different beast21:23
lkclit's really important not to call them predicates21:23
lkclbecause "sm=NN" is a predicate21:23
* lkcl thinks..21:24
lkcl"/dm=NN" is a predicate21:24
lkclbut "/ff=NN" is *not* a predicate21:24
lkcland neither is "RC1"21:24
lkclwhat can we call them...21:24
lkclany suggestions?21:24
ghostmansdNo idea21:24
ghostmansdFor now they are called predicates in insndb branch21:24
lkclCR-bit-selectors? (clumsy)21:24
ghostmansd1 sec21:25
lkclah i know: i have used "BO-selectors" before now21:25
programmerjakeff=NN -- NN is inv?-cr-bit21:25
lkclbecause actually they are identical to Branch bits BO0 thru BO221:25
lkclBO[0], BO[1], BO[2]21:25
lkclthey do literally exactly the same thing, and should even be in the same order as the branch-conditional bits from the BO field21:26
ghostmansdStarting from here I made some enums21:26
ghostmansdBetter names are welcome21:26
lkclRC1=3 needs to be removed21:26
lkclit cannot and will never be directly associated with predicates21:27
lkclRC1 and ~RC1 if anything should be their own separate Enum class21:27
lkclsomething like that21:27
lkcl 404 @unique21:28
lkcl 405 class SVP64PredRC1(Enum):21:28
lkcl 406     RC1 = 021:28
lkcl 407     RC1_N = 121:28
ghostmansdPlease scroll below21:28
lkcllike that.21:28
lkcl 290 @unique21:28
lkcl 291 class SVP64PredMode(Enum):21:28
lkcl 292     ALWAYS = 021:28
lkcl 293     INT = 121:28
lkcl 294     CR = 221:28
lkcl 295     RC1 = 321:28
lkclline 295 must be removed.21:28
ghostmansdSVP64PredMode.RC1... I don't remember why I added it. Perhaps I stored some table somewhere.21:28
ghostmansdWhich has all this stuff which has inv and bits21:29
lkcl 451     RC1 = SVP64PredRC1.RC121:29
lkcl 452     RC1_N = SVP64PredRC1.RC1_N21: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
lkclthose two lines need to be removed21:29
ghostmansdThat's the reason: I groupped them to check which arguments are accepted21:30
lkcli think...21:30
ghostmansdthat's for ff and pr21:30
lkcl 432 class SVP64Pred(Enum):21:30
ghostmansdff or pr accept either "CR" or "RC1" -typed21:30
lkclthat should not be called "SVP64Pred" if it accepts ff and pr21:30
lkclif however it is *actually* SVP64Pred, then lines 451 and 452 must be removed21:31
ghostmansdSVP64Pred is kinda umbrella for everything -- INT, CR and RC121:31
ghostmansdJust a way to construct any of these21:32
lkclyyeah hence the confusion21:32
ghostmansdKinda wrapper for "anything which belongs to INT/CR/RC1"21:32
lkcland calling RC1 "a predicate" when it's confused with "a predicate mask"21:32
ghostmansdI think it's the naming that must be changed21:32
* lkcl tck tck tck *thinks*...21:32
lkclah, i know - they need to be separated21:33
lkclto totally separate classes21:33
ghostmansdThey kinda already are21:33
lkclwhere "the-one-which-does ff and pr" would have duplicate LT/GE/GT etc21:33
lkcland would happen to have RC1 and RC_N21:33
ghostmansd 433     ALWAYS = SVP64PredInt.ALWAYS21:33
ghostmansd 451     RC1 = SVP64PredRC1.RC121:34
lkclbut would NOT have R3, R10, etc.21:34
lkclyou absolutely cannot have "ff=r3" for example21:34
ghostmansdYes, and this is checked21:34
ghostmansdclass SpecifierFFPR(SpecifierPredicate):21:34
ghostmansd    @classmethod21: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
ghostmansdAgain, this is just a misnomer21:35
lkclcould you separate it to a totally different enum?21:35
ghostmansd433     ALWAYS = SVP64PredInt.ALWAYS21:35
lkclaiyaaa barometic pressure change, intense pain21:35
ghostmansdDon't you see the RHS?21:36
lkcli have to go, i am in freaking serious pain21:36
ghostmansdthere's a separate class for all of them21:36
lkcli can't even concentrate on the keyboard let alone what you're putting in front of me21:36
lkclgtg.  NOW.21:36
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc21:47
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC22:05
*** lkcl <lkcl!> has quit IRC22:24
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc23: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 causing23:32
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC23:57

Generated by 2.17.1 by Marius Gedminas - find it at!