Tuesday, 2022-09-13

*** octavius <octavius!~octavius@> has quit IRC00:50
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC09:42
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC09:42
*** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC09:42
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC09:42
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC09:42
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC09:42
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc09:48
ghostmansdlkcl, could you, please, check 917, 918, 919 and 920? I re-allocated the budget from 917 to its children.10:19
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc10:20
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc10:20
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc10:20
*** psydroid <psydroid!~psydroid@user/psydroid> has joined #libre-soc10:20
*** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc10:20
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc10:21
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC11:11
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc11:44
ghostmansdlkcl, in CR ops at https://libre-soc.org/openpower/sv/cr_ops/12:18
ghostmansdHow do we differ 3-bit and 5-bit?12:18
ghostmansdI see some explanation below, but confused what to look at in the code12:20
lkclghostmansd, please put it back12:22
programmerjakei'd expect you'd look at the output cr field, if it is a 5-bit field in the suffix, you can use 3-bits in the prefix, otherwise you need 5-bits in the prefix12:22
ghostmansdWhat do you mean to put it back? The tasks?12:22
lkclplease restore those budgets immediately.  all budgets have to be exactly as they are in the RFP system12:22
ghostmansdAh OK12:22
ghostmansd1 sec12:23
lkclwe have to put in requests for authorisation to restore them12:23
lkclwe have to put in requests for authorisation to change them12:23
ghostmansdI thought it's OK to move budget from parent to children12:24
programmerjakelkcl: this is exactly what I warned you about...if you don't tell people in a way they notice they won't know to not change budgets.12:24
ghostmansd> i'd expect you'd look at the output cr field, if it is a 5-bit field in the suffix, you can use 3-bits in the prefix, otherwise you need 5-bits in the prefix12:25
lkclit was - it's not ok for the next 3-4 weeks.12:25
ghostmansdThis needs some explanation. I'm dealing with the prefix; should I take a look at the operand?12:25
lkclhttps://bugs.libre-soc.org/show_bug.cgi?id=864 - update the field to put the submitted date12:25
lkclhttps://bugs.libre-soc.org/show_bug.cgi?id=838 and this one12:26
programmerjakere cr fields, i'll let lkcl explain, he's more familiar with that part12:27
ghostmansdOK, sorry, folks12:27
ghostmansdI didn't think that at this point even parent<->chilren relationship should be preserved as is.12:28
ghostmansdMy apologies.12:28
programmerjakebasically everything except stuff assigned to the "Future" milestone needs to not be modified, marking stuff paid/submitted is just about the only exception afaict12:30
programmerjakefor budget ^12:30
ghostmansdAh OK, now it's clear12:31
programmerjakecr fields -- i got them backwards by mistake...the 3/5-bit naming in the prefix is referring to the size of the cr field in the suffix12:34
ghostmansdEverything related to CRs is really confusing. I'm dealing with the prefix and need to know whether it's 3-bit or 5-bit. But any CR operand can be either 3-bit or 5-bit, and there can be several of those.12:37
programmerjakethe one that matters is the cr operand that is written to by the suffix instruction12:38
programmerjakeso you have to look at the suffix instruction to know which one to use12:39
ghostmansdSo we only look at the operand marked as destination one?12:41
ghostmansdd:BT, d:BF, etc.?12:42
programmerjakeso, if the suffix is XL-form with BT, then you use the 5-bit form of the prefix, because BT is 5 bits12:43
programmerjakeghostmansd: yes afaict12:43
ghostmansdOK, cool!12:43
programmerjakelkcl: can you verify we're correct?12:46
ghostmansdI've pushed  CR ops RM with all modes except ff3/ff5.12:53
lkclprogrammerjake, ghostmansd it's all very simple - if it's got "F" in the name it's a 3-bit CR-Field13:19
lkclBF and BFA.13:19
lkclthose are the only two13:19
lkcleverything else is 5.13:19
ghostmansdconsidering all this weird stuff, I can pretty much guess what F stands for13:19
lkclduh :)13:19
*** octavius <octavius!~octavius@> has joined #libre-soc13:20
lkclthe only other one is mfcr mtcr which is the *entire* 32-bit scalar CR register13:20
ghostmansdand "it's got" -- you mean the only one operand marked as destination?13:20
ghostmansdbecause there might be up to 3 operands IIRC13:20
lkclbut that needs dealing with in a separate way.13:20
ghostmansd(in these instructions)13:20
lkclin the crops group? yes only 3 operands.13:21
lkclas a general rule everything maxes out at 3-in 2-out. Rc=1 and XER.CA/OV/SO push that definition slightly13:21
ghostmansdOK, so the algorithm for ff3/ff5 is: 1) iterate through the operands and find the destination one; 2) check if it's 3-bit or 5-bit (it's 3-bit if it's in list (BF, BFA)13:23
lkclERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #919, calculated value 50013:26
lkclERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #919, calculated value 50013:26
lkclERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #918, calculated value 100013:26
lkclERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #918, calculated value 100013:26
lkclERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #917, calculated value 450013:26
lkclERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #254, calculated value 1400013:26
lkclERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #140, calculated value 5150013:26
lkclplease don't edit budgets in future13:26
lkclhttps://bugs.libre-soc.org/show_bug.cgi?id=917 EUR 2500 is entirely for you (for all 3 sub-sub-tasks)13:29
lkclthe sub-sub-tasks are far along enough that i'm happy to say "they're done"13:29
lkclwe're just waiting for michiel13:30
lkclok i sorted the errors.  i removed the sub-sub-task budget allocations.  you still get the same amount13:30
ghostmansdThanks Luke13:32
lkclwe have to be stupidly careful with the budget system. it's audited13:33
lkcllike, by the EU Commission.13:33
lkclif we fuck it up NLnet gets into legal trouble.13:33
ghostmansdSorry, I won't ever enter the budget again.13:34
lkcli approved the two bugreports13:34
ghostmansdThat was just a stupid assumption about parent/children tasks.13:34
lkclit's checked by the program called "budget-sync" (which you can run yourself)13:34
programmerjakein utils.git13:34
lkclbut there's no "rollback" - no safety net13:35
programmerjakerollback -- you look at the edit history and figure out how you messed up then fix it manually13:36
ghostmansdyet another reason to never dive into this13:36
ghostmansd(even the former reason is sufficient, though)13:36
programmerjakei wrote budget-sync because we had trouble catching errors manually13:37
ghostmansdGot it13:38
programmerjakerunning budget-sync is also very handy for figuring out what tasks you have yet to be paid on...it generates a handy markdown output for everyone listed in the bugzilla database13:39
ghostmansdlkcl, please don't yet merge anything from dis, it's under rebase13:39
lkclghostmansd, ack13:51
lkcli run it frequently and upload here https://libre-soc.org/task_db/mdwn/13:52
* lkcl need to do the complex FSM for pack/unpack in ISACaller, now13:52
programmerjakereading https://www.supergoodcode.com/sp33d2/14:12
programmerjake> Obviously I’m talking about optimization, the process by which a smart and talented reader of StackOverflow copies and pastes code in exactly the right sequence such that, upon resolving all compilation errors, execution of a program utilizes fewer resources.14:13
ghostmansdOK I think I completed both CR and Branch14:15
ghostmansdI tested CR operands check with a hack -- I temporary assigned prefix for crand to ((1 << 24) - 1).14:16
ghostmansdIn other words, totally cheated.14:16
programmerjakethat article is filled with more gems like that :)14:16
ghostmansdlkcl, test_dis.py is OK, I think it's safe to rebase after tests are passed14:17
ghostmansdWhat'd be the next point? Simply printing the stuff from the fields?14:17
ghostmansdDo we have the reconstruction depicted somewhere?14:20
ghostmansdOr I should simply do what's in pysvp64asm in a backward way?14:20
ghostmansdAh yeah, likely the latter; e.g. outputting subvl=ZZZ is not as good as vec2/vec3/vec4.14:21
ghostmansdStill it'd be great if we had some page where there's summary, with the list of all opmodes and description what fields should be.14:23
ghostmansdBy opmodes I mean this: opmodes = opcode.split("/")14:23
ghostmansdFrom pysvp64asm14:23
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC14:28
lkclghostmansd, see https://bugs.libre-soc.org/show_bug.cgi?id=917#c4014:29
lkclpack/unpack is now an overload of elwidth but *only* for "normal" mode, and that's a temporary hack14:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC14:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:42
* lkcl manic hysterical cackles15:03
lkclfaakinellfire FSM-based dual looping is complicated15:03
lkclesp. when you have to swap the order of the inner and outer loops based on a runtime decision15:04
lkclyes i know, a list of the /modifiers is on the (long) todo list15:40
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc16:43
ghostmansd[m]lkcl, do these PU changes need a doc update?16:47
ghostmansd[m]Because (deep breath!) I did based on docs, I didn't have to study this signal madness16:48
ghostmansd[m]For instructions, I look at fields.text, because I know where and what to find. Not the same with all these modes, it'd have taken several days to understand how it's mapped into signals.16:49
ghostmansd[m]So I suggest to at least update the docs so that I could look into them instead of wandering through the code.16:50
programmerjakelkcl: currently wiring up fp support in TestRunnerBase, any suggestions?17:05
programmerjakelkcl: is PowerDecode2.init supposed to pass regreduce_en to super().init? it passes constant False and ignores the input argument, which seems like a mistake17:15
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc17:48
ghostmansd Hell Luke, either I did't push the recent version or you rebased something else. The code is doomed. :-)17:48
ghostmansdPerhaps this is the reason for errors, too.17:48
ghostmansdIt seems like you rebased dis without pull...17:49
ghostmansdI did some force pushes later.17:49
ghostmansdlkcl, I'm not sure how to handle the conflict above ^17:59
ghostmansdI'd rather preferred a force rewrite, to be honest, because otherwise it's just unstable code in the master.17:59
*** tplaten <tplaten!~isengaara@55d45726.access.ecotel.net> has joined #libre-soc18:01
ghostmansdI think I know why at least part of this doesn't work. We don't handle signed, and, frankly, I have no idea how to determine this.18:31
ghostmansdI can go over PPC_OPERAND_SIGNED in binutils, though.18:37
programmerjakeghostmansd, if you need something to do while waiting, I'm almost done with my part of #899 and will be waiting on you and lkcl to finish18:39
ghostmansdI'm not waiting, started looking at signed operands in binutils. :-)18:39
programmerjakeah, ok.18:40
ghostmansdWhat's expected on binutils side?18:40
ghostmansdWhich opcodes must be added?18:40
programmerjakefor #899? the full list is this (plus f*. opcodes) https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=6c71462a0683bcfedcdb5c3e515d86ecf541cd9c;hb=56d807a8c26a358850220a34b982952fdf341027#l40918:43
ghostmansdso these plus Rc-enabled, right?18:45
ghostmansdWow, looks like a big chunk of work in binutils.18:46
ghostmansdI'll start tomorrow, OK?18:46
programmerjakeI'd suggest doing what I did for most of the stuff in openpower-isa.git -- copy from the tail end minor_63.csv (all fptrans) and use a giant regex to reformat it to do what you want18:47
ghostmansdIt's not that simple; binutils have some specific operands handling.18:48
ghostmansdHm. I'll think how to handle it.18:49
programmerjakethey're all X-form, 3 different groups where each group is identical except for mnemonic and XO18:49
ghostmansdPerhaps I'll come with something inventive.18:49
ghostmansdWhich are the groups?18:49
programmerjakethere's the f* FRT,FRA group, the f* FRT,FRA,FRB group and the f* FRT,FRA,RB group18:50
ghostmansdAha, so they differ by operands.18:50
ghostmansdOK, got it.18:50
ghostmansdThere's also test needed for each one of these, but perhaps these can be generated too.18:51
programmerjakewithin each group, only XO and the mnemonic vary, so it's pretty regular18:51
ghostmansdThese operands are all 5-bit, right?18:52
ghostmansdOK this simplifies the task. Though, on second thought, insndb is aware of operands span, so it's not a problem anyway.18:53
ghostmansd^ I'll start tomorrow, OK?18:53
programmerjakek, thx!18:53
ghostmansdLikely the day after tomorrow, tomorrow will be quite occupied.18:53
ghostmansdAnyway, I think I'll be able to make at least part of the work automatic.18:53
programmerjakeoh, actually the unary ops are f* FRT,FRB, not FRA...oops18:56
ghostmansdThat's OK anyway :-)18:56
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC19:15
lkclghostmansd[m], start small, don't think you have to tackle all of those.  i'm quite happy with a subset19:25
ghostmansd[m]Well I saw 32 of these IIRC, and many of them are form of the same (e.g. BD has some other forms in binutils).19:26
* lkcl currently in the middle of complex ISACaller update19:27
ghostmansd[m]Also, interestingly, it appears that this split D implemented recently, must be signed too19:27
lkclyes they're all either A-Form or X-Form. honestly a no-brainer19:27
ghostmansd[m]lkcl, please check about the rebase, we fucked it up19:27
ghostmansd[m]Or, well, perhaps I fucked it up19:27
lkclgreat! yay!19:27
ghostmansd[m]No idea how it happened19:28
programmerjakelkcl: if you're talking about fptrans, they're now all X-FORM19:28
ghostmansd[m]My best bet is that you forgot to pull :-)19:28
lkclgenerally it's inadviseable to use force-push on anything19:28
ghostmansd[m]On branches this is perfectly fine, branches are not supposed to be merged until ensured they are stable19:28
ghostmansd[m]Moreover, this is the best option to cleanup patch before publishing it19:29
ghostmansd[m]e.g. if you had some fixup after push19:29
ghostmansd[m]I agree this is not an option for master19:29
lkclcan i leave it with you, i have to get back to ISACaller, it's extremely complex19:31
programmerjakeif you're force pushing, you can use --force-with-lease to ensure you didn't accidentally overwrite something you didn't see, it checks that you're origin/master matches the remote master, if you're pushing to master19:31
programmerjakeI wrote master, but replace master with the appropriate branch name19:32
lkclprogrammerjake, you mean "your origin/master" not "you are origin/master"19:33
lkclit would be very weird to be equal to an origin/master whilst performing that check :)19:33
programmerjakeyeah, you know what I meant despite my typos19:33
lkcli did - couldn't help it :)19:33
lkclfrickin sub-steps on loops aren't updating properly. reaaally wish i could do this as an iterator.19:36
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc19:39
ghostmansd[m]Nah, that'd be way too simple19:43
ghostmansdmax = operand->bitm;19:44
ghostmansdright = max & -max;19:44
ghostmansdmin = 0;19:44
ghostmansdif (signopt)19:44
ghostmansd    min = ~(max >> 1) & -right;19:44
ghostmansdelse if (signed)19:44
ghostmansd    max = (max >> 1) & -right;19:44
ghostmansd    min = ~max & -right;19:44
ghostmansdAnybody experienced in bit operations?19:45
* lkcl snorts19:45
ghostmansdWhat does it mean, translated to human?19:45
lkclno chance19:45
ghostmansdAnd assuming Python integers19:45
ghostmansdbitm is a mask (0x1f for 5-bit)19:45
ghostmansdBut the rest looks kinda alien to me19:46
ghostmansdDamn it, binutils!19:46
ghostmansdI understand they sign extend...19:46
ghostmansdBut the rest?19:46
ghostmansd     if ((o->flags & PPC_OPERAND_SIGNED) != 0)19:47
ghostmansd       sign_extend (op);19:47
ghostmansdOK they basically limit the range19:55
ghostmansde.g. with mask 0b11 ranges become -2..119:56
ghostmansdso surprising, the operand is called PPC_OPERAND_SIGNED, who could imagine19:57
ghostmansdwhoa, lkcl, thanks for the to_signed method20:09
ghostmansdlkcl, could you, please, run tests on dis branch when you have time?20:19
ghostmansdThere's one known failure in pysvp64dis, with `mtspr 288,0` instruction.20:19
ghostmansdit gets disassembled as `mtspr 9,0`.20:19
ghostmansdAs far as I know, SPR is not considered to be special in pysvp64dis, and perhaps it should've been.20:20
ghostmansdOther than that, looks really good.20:28
*** tplaten <tplaten!~isengaara@55d45726.access.ecotel.net> has quit IRC20:31
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC20:38
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc21:00
lkclghostmansd[m], ack willdo21:23
ghostmansd[m]I couldn't get what you mean in the comment to 917... I already pushed the patch for test, it worked for me21:23
ghostmansd[m]Except for mtspr part.21:24
lkcli ran against master21:24
programmerjakemeeting in 22min21:39
programmerjake21 now21:39
*** octavius <octavius!~octavius@> has quit IRC22:59

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!