| markos | lkcl, ... and done, all values are reproduced, only thing that remains is getting the max and position, will commit now all work so far just in case my disk decides to die on me while I sleep :D | 01:15 |
|---|---|---|
| markos | ref cost: | 01:15 |
| markos | 04858917 05cf5742 021c7323 01c68c56 05931132 03de109a 02f8e489 00f02d4b | 01:15 |
| markos | reg 24 04858917 05cf5742 021c7323 01c68c56 05931132 03de109a 02f8e489 00f02d4b | 01:15 |
| markos | gn, ttyt | 01:17 |
| programmerjake | yay! | 02:24 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:23 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.179> has joined #libre-soc | 08:22 | |
| lkcl | markos, sorry - here's the syntax examples https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/test_pysvp64dis.py;h=808b3b504a4a1192efce066ac4d16256a59b3896;hb=a65084c24742b43e79da714e5cd08f0d24a83eab#l312 | 08:58 |
| markos | thanks, it will have to wait for maxs impklementation first :) | 09:01 |
| lkcl | although i'm not sure why RC1 is necessary (annoyingly), /ff=eq should be fine | 09:02 |
| lkcl | ack | 09:02 |
| lkcl | no you don't need it. | 09:02 |
| lkcl | i sent the sequence yesterday. | 09:02 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-10-13.log.html#t2022-10-13T23:05:41 | 09:03 |
| markos | maybe it's something in binutils | 09:03 |
| lkcl | you don't need failfirst | 09:04 |
| lkcl | failfirst is an optimisation to terminate at the first compare that's equal | 09:04 |
| markos | indeed | 09:04 |
| * lkcl thinks do you need the mapreduce max? | 09:04 | |
| lkcl | yes. sorry | 09:05 |
| lkcl | it's in sv/trans/svp64.py | 09:05 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD#l484 | 09:06 |
| lkcl | try a vertical-first loop instead | 09:08 |
| markos | binutils is giving me unrecognized opcode for maxs, I'll wait for ghostmansd[m] | 09:09 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_setvl.py;h=058a6be794a7416c0732b2551c92ad3a79bce45b;hb=a65084c24742b43e79da714e5cd08f0d24a83eab#l934 | 09:09 |
| markos | I'm confused, vertical-first loop to replace what? | 09:10 |
| lkcl | when i'm a little more awake i'll do a CTR-based thing. | 09:10 |
| lkcl | not replace. | 09:10 |
| lkcl | get. | 09:10 |
| markos | to get the position of max? | 09:10 |
| lkcl | yes | 09:10 |
| markos | ack | 09:10 |
| lkcl | you can extract the index by conditionally using an svstep to extract the srcstep *in the middle* of the vertical-loop | 09:12 |
| lkcl | you remember how sv.svstep extracts a *vector* of srcsteps, to create a sequence 0,1,2,3,.... ? | 09:12 |
| markos | I remember how I can use svstep to generate the sequence to some registers yes | 09:13 |
| lkcl | there's nothing stopping you from extracting *the current* srcstep when using vertical-first mode, in exactly the same way | 09:13 |
| lkcl | use it exactly like you would a standard scalar loop | 09:15 |
| lkcl | tmp_idx = -1 | 09:15 |
| lkcl | max_val = -1 | 09:15 |
| lkcl | for .... | 09:15 |
| markos | ok, I have to see the code that does it, I am with very little sleep right now and my comprehension is limited, coffee hasn't kicked in yet :/ | 09:15 |
| lkcl | if array[i] > max_val: { tmp_idx = i; max_val = array[i] } | 09:15 |
| lkcl | :) | 09:15 |
| lkcl | yeah i am not awake either | 09:15 |
| lkcl | ghostmansd[m], can we first rebase in the ldst-postinc branch? | 09:49 |
| ghostmansd[m] | lkcl, does it have many changes? | 09:51 |
| ghostmansd[m] | If so, rebase it with master, I'll rebase my local stuff too | 09:52 |
| lkcl | ack | 09:53 |
| lkcl | done. no, not a lot | 09:53 |
| ghostmansd[m] | Ok just rebase it, I'll integrate these changes too | 10:16 |
| lkcl | on the "reserved" area in ld/st-imm i added two new mode-bits | 10:17 |
| lkcl | only one is tested so far (/pi). | 10:17 |
| lkcl | /lf is still TODO but is low priority | 10:18 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.179> has quit IRC | 10:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.84> has joined #libre-soc | 10:30 | |
| markos | this is the snippet I've written for max/pos: | 11:05 |
| markos | setvl 0,0,8,0,1,1 # Set VL to 8 elements | 11:05 |
| markos | #sv.maxs/mr max, max, *cost | 11:05 |
| markos | sv.cmp/ff=eq 0, 1, *cost, max | 11:05 |
| markos | svstep retval, 5, 0 | 11:05 |
| markos | sv.maxs is commented out as it's not supported yet | 11:05 |
| lkcl | i'm currently investigating, there's a bug in vertical-first mode when used with predication | 11:06 |
| markos | sv.cmp/ff=eq also fails with binutils | 11:06 |
| markos | Error: ffirst BO only possible when Rc=1 | 11:06 |
| lkcl | i said don't use fail-first | 11:06 |
| markos | ok, what happens if 2 values are equal to max? | 11:06 |
| lkcl | let me write the vertical-first loop | 11:07 |
| lkcl | and fix the bug | 11:07 |
| markos | not really relevant to this particular unit test but curious | 11:07 |
| lkcl | you want the index of the maximum element, i have to fix this bug | 11:07 |
| markos | ok | 11:07 |
| lkcl | when the predicate-bit is ok, things are fine. | 11:14 |
| lkcl | when it's not ok, "skipping" occurs (which it should not), which triggers "end of loop" | 11:15 |
| lkcl | ngggh | 11:15 |
| lkcl | that's only supposed to happen in horizontal-mode | 11:15 |
| lkcl | damn | 11:23 |
| lkcl | going to take a lot more to sort out | 11:23 |
| lkcl | markos, nuts to it. can i suggest simply putting in the RFP now. | 11:28 |
| lkcl | i'm closing the bugreport now | 11:29 |
| markos | I'll submit the updated code | 11:30 |
| lkcl | bugreport is now closed. task declared completed. i'm putting in an RFP now. | 11:31 |
| markos | :D | 11:33 |
| lkcl | done | 11:34 |
| *** octavius <octavius!~octavius@249.147.93.209.dyn.plus.net> has joined #libre-soc | 11:40 | |
| markos | lkcl, just added a comment | 11:44 |
| markos | with some explanation | 11:44 |
| markos | let me know if I should add anything more | 11:44 |
| markos | sent RFP as well | 11:48 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:50 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:54 | |
| lkcl | brilliant, confirmed | 12:03 |
| markos | if we had one more week, I'd do the mp3 as well :) | 12:10 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.84> has quit IRC | 12:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.123> has joined #libre-soc | 13:01 | |
| lkcl | markos, i got it - the problem is using predication (at all) within vertical-first | 14:11 |
| lkcl | by using isel as a substitute for sv.max i managed it | 14:11 |
| lkcl | committing in 1 sec | 14:12 |
| lkcl | 985 lst = SVP64Asm(["setvl 0, 0, 5, 1, 1, 1", | 14:17 |
| lkcl | 986 'sv.cmp 0, 1, *4, 14', # r8 contains the temp | 14:17 |
| lkcl | 987 'sv.isel 14,*4,14,1', # copy if cmp was greater | 14:17 |
| lkcl | 988 "svstep. 12, 6, 0", # get srcstep | 14:17 |
| lkcl | 989 'sv.isel 10,12,10,1', # copy if cmp was greater | 14:17 |
| lkcl | 990 "svstep. 0, 1, 0", # svstep (Rc=1) | 14:17 |
| lkcl | 991 "bc 6, 3, -0x24" # branch to cmp | 14:17 |
| octavius | lkcl, is there a way to set up an ubuntu chroot? I wanted to try setting up tasyagle using ubuntu instead | 14:22 |
| octavius | within a host debian that is | 14:22 |
| markos | debootstrap/vmdebootstrap | 14:24 |
| markos | ... which is now vmdb2 | 14:24 |
| markos | but for a plain chroot debootstrap should work just fine | 14:25 |
| markos | lkcl, why the branch, does it repeat until done? | 14:27 |
| markos | why not use sv.max? | 14:30 |
| lkcl | yyep. | 14:39 |
| lkcl | step | 14:39 |
| lkcl | compare-branch | 14:39 |
| lkcl | step | 14:39 |
| lkcl | compare-branch | 14:39 |
| lkcl | step ... end-reached (srcstep == VL-1): EQ-bit set to 1 | 14:39 |
| lkcl | compare-branch fails, EXIT | 14:40 |
| lkcl | because _you_ cannot use sv.max right now. | 14:40 |
| lkcl | plus, the same sv.cmp can be used for both isel()s | 14:40 |
| lkcl | using the same trick, it avoids the need for a branch-jump over a copy of the current-max-index and the current-max-value | 14:41 |
| lkcl | hm we need "max." to actually perform a cmp. | 14:42 |
| lkcl | and maxs. and min. and mins. | 14:42 |
| lkcl | you did say you needed an _array_-based max-detection-and-index-of? | 14:43 |
| markos | yes | 14:46 |
| lkcl | ok then you can use that as a recipe | 15:01 |
| lkcl | you may have to tweak it a bit so it definitely uses ">" rather than ">=" | 15:02 |
| lkcl | otherwise if there are duplicates it'll get you the *last* element's index rather than the first | 15:03 |
| lkcl | which might involve some "crands" because sv.isel can only do testing on one bit | 15:03 |
| lkcl | crands or crors | 15:04 |
| lkcl | the cmp produces a CR0 ("sv.cmp 0,..." targets CR0) of EQ,LT,GT | 15:05 |
| lkcl | but if you wanted GE you have to OR the EQ and GT bit together | 15:05 |
| lkcl | markos, all those batches have me drumming my fingers :) | 15:30 |
| lkcl | 203 setvl 0,0,4,0,1,1 # Set VL to 4 elements | 15:30 |
| lkcl | 204 sv.add *psum_alt+0, *psum_alt+0, *img+0 | 15:30 |
| lkcl | 205 sv.add *psum_alt+1, *psum_alt+1, *img+4 | 15:30 |
| markos | yes, I know they are not optimal | 15:30 |
| lkcl | like, that's exactly what REMAP is supposed to *not* have to have :) | 15:31 |
| markos | I really should get a better grasp of remap | 15:31 |
| lkcl | but, it'll need some thought and evaluation as to what would be needed | 15:31 |
| markos | but I can do that gradually and convert the function to perhaps half the size? | 15:31 |
| lkcl | well i want to put a specific task/budget on it | 15:31 |
| lkcl | am making notes, now | 15:32 |
| markos | what I would really like to do is get a cookbook started, with SVP64 best practices, eg. when you have this C source, here's how you can do it in SVP64, etc | 15:33 |
| lkcl | yehyeh | 15:33 |
| lkcl | raise a bug about it, link it to #952 | 15:33 |
| lkcl | then it goes on the list to get some EUR for doing it | 15:34 |
| markos | component: source code or website? | 15:35 |
| lkcl | website | 15:36 |
| lkcl | for no particular reason :) | 15:37 |
| lkcl | frickinell that's 13 bugreports already linked to #952 in only 10 minutes of looking | 15:37 |
| markos | how to link? | 15:38 |
| markos | #953 | 15:38 |
| markos | blocks or depends on? | 15:38 |
| lkcl | ermm...ermermerm... blocks | 15:38 |
| lkcl | oh btw, all of these? | 15:39 |
| lkcl | 259 setvl 0,0,8,0,1,1 # Set VL to 8 elements | 15:39 |
| lkcl | 260 sv.lha *img, 0(ptr_copy) # Load 8 ints from (ptr_copy) | 15:39 |
| lkcl | 261 add ptr_copy, ptr_copy, stride # Advance ptr_copy by stride | 15:39 |
| lkcl | there *is* a way to do those in a loop | 15:39 |
| lkcl | but it needs something called "hphint" in Vertical-First Mode to be implemented, first | 15:39 |
| markos | I understand setvl also provides a stride also? | 15:39 |
| lkcl | "hphint" is like a hybrid Vfirst-Hfirst | 15:39 |
| lkcl | no it doesn't | 15:39 |
| lkcl | but there's a planned "horizontal-parallelism hint" for VF mode | 15:40 |
| markos | ok | 15:40 |
| lkcl | basically what that does is, it says | 15:40 |
| lkcl | "yes i know we're in Vertical-First Mode, but you're allowed to do up to N elements in *horizontal* batches" | 15:40 |
| lkcl | it's primarily for when you have loops like this: | 15:40 |
| markos | yup, that's stride mode there | 15:41 |
| markos | used in pretty much *all* video codecs | 15:41 |
| lkcl | for i in range(VL): mem[i+2] += mem[i] | 15:41 |
| lkcl | where a programmer knows that you can do up to *two* elements - safely - in parallel | 15:41 |
| lkcl | without memory-corruption | 15:41 |
| markos | cool | 15:42 |
| lkcl | but... it's... complicated by the fact that if implemented naively, we'd need to store *even more* state in SVSTATE | 15:42 |
| lkcl | yet more indices (yet more srcsteps, dststeps, and sub-steps) | 15:42 |
| lkcl | so i really have to think about it, first | 15:43 |
| markos | sure, I think now that the deadline is (almost) over, we can sit back and think things more carefully now | 15:43 |
| lkcl | yes. thank goodness | 15:47 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.123> has quit IRC | 16:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.157> has joined #libre-soc | 17:13 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.157> has quit IRC | 17:23 | |
| *** octavius <octavius!~octavius@249.147.93.209.dyn.plus.net> has quit IRC | 17:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.121> has joined #libre-soc | 17:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.162> has joined #libre-soc | 17:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.162> has quit IRC | 17:53 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:57 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:57 | |
| ghostmansd | markos, lkcl, https://bugs.libre-soc.org/show_bug.cgi?id=954 | 18:06 |
| ghostmansd | Whilst we're here, I'll raise tasks for the rest of them, first being https://bugs.libre-soc.org/show_bug.cgi?id=955 | 18:06 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=956 | 18:09 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=957 | 18:12 |
| lkcl | ghostmansd, ack started cross-referencing | 18:12 |
| ghostmansd | hang on | 18:12 |
| ghostmansd | I'm also creating a parent task :-) | 18:12 |
| ghostmansd | 1 sec | 18:12 |
| ghostmansd | this is meta task: https://bugs.libre-soc.org/show_bug.cgi?id=958 | 18:14 |
| ghostmansd | shoulda started with it but only then found all these reside in av.mdwn | 18:15 |
| ghostmansd | lkcl, are these covered by cavatools? I remember you mentioned that we're able to reserve some budget for binutils from cavatools. | 18:15 |
| lkcl | yehyeh | 18:16 |
| ghostmansd | On one hand, I'm pissed by the fact that we still don't generate these; on the other, adding several instructions manually is way less work than rewriting the whole binutils logic with the tables (this is quite hard-coded). | 18:16 |
| lkcl | irony... | 18:17 |
| ghostmansd | I'd like to finish binutils as quick as possible, since most of the time is needed for cavatools. | 18:19 |
| ghostmansd | I don't want us to end up in the situation when we lack time to complete cavatools. | 18:20 |
| lkcl | i've 4 students from india considering helping | 18:20 |
| lkcl | from the OpenPOWER Academic Working Group | 18:21 |
| ghostmansd | I mean, I get the benefits of generating this, but would rather prefer doing this in some separate way, this is a huge task, mostly consisting of boring cross-checking how much stuff is broken when we migrate to autogeneration (spoiler: I expect a lot). | 18:21 |
| lkcl | they are 3rd year UGs so have done a compiler course | 18:21 |
| ghostmansd | That'd be great! | 18:21 |
| ghostmansd | I'll add min/max routines now, for markos. | 18:22 |
| ghostmansd | I hope it won't take much time, hopefully this is less complicated than svshape2. :-) | 18:22 |
| lkcl | yehyeh :) | 18:22 |
| markos | ghostmansd, thanks, I think we are now going to be tackling issues at a much leisurely pace -not lazy but we will not have to stay up till 3am to get it running :) | 18:23 |
| markos | s/much/much more | 18:23 |
| markos | lkcl, make sure they know their stuff | 18:24 |
| ghostmansd | Don't worry, coding at 3am is my natural modus operandi :-D | 18:24 |
| markos | last year I hired an MSc from CompSci who claimed to know his C and Linux, turns out I had to teach him C data types and that C/C++ is NOT the IDE Visual Studio | 18:25 |
| * lkcl facepalm | 18:25 | |
| markos | after teaching him 3 hours/day *every* day to get him at a good state, he told him I should double his salary or he would leave because he found another better job abroad | 18:26 |
| lkcl | cheeky bugger | 18:26 |
| markos | turns out I was basically paying him to train him | 18:26 |
| markos | never again | 18:26 |
| lkcl | i hope you said "no" | 18:26 |
| markos | ofc | 18:26 |
| markos | was my fault, I was against technical tests on people | 18:27 |
| markos | because I hate them myself, find them wrong in principle | 18:27 |
| markos | so when someone claims on their CV that they have 3/5 skills in C/C++ I take that as the truth | 18:28 |
| markos | I mean 5/5 is for Stroupstroup -or what's his spelling anyway | 18:28 |
| markos | or for LLVM engineers | 18:28 |
| markos | with modesty I might grade myself a 3/5, maybe 3.5/5 if I'm being extremely generous, definitely not a 5/5 | 18:29 |
| markos | so I took this guy on his honesty | 18:29 |
| markos | boy was I mistaken | 18:29 |
| markos | I mean, I know they don't teach C and such languages to such depth in university anyway | 18:30 |
| markos | not like they used to | 18:30 |
| markos | so I expected it to be a case of some training | 18:30 |
| markos | but the lack of knowledge in pretty much everything was obvious after the first couple of months | 18:31 |
| markos | problem is I'm also a nice guy, I thought "oh but he's a good kid, I can just train him and he'll be fine" | 18:31 |
| markos | that's why I'm not a good business man on that aspect, I'm too sentimental | 18:32 |
| lkcl | funny how you actually need to be quite pathological | 18:32 |
| markos | so after 9 months of training, he *finally* was able to do a simple task | 18:32 |
| markos | and just when I thought "finally, we can do business" | 18:33 |
| markos | "hey, I'm leaving for Germany found a job there as a consultant, unless you double my salary" | 18:33 |
| markos | sorry for the rant | 18:33 |
| lkcl | hey not a problem :) | 18:33 |
| markos | but you touched a sensitive cord there | 18:34 |
| markos | there is no fucking chance I'm hiring anyone in the future unless I pass them through a painstaiking technical test myself, not just some random online crap | 18:34 |
| markos | this guy just screwed the next ones | 18:34 |
| lkcl | does anyone know how to specifically disable locking on glibc6? | 18:38 |
| lkcl | i'm trying to get a simple systemcall on putchar | 18:38 |
| lkcl | but there's a massive stack of sys_futex syscalls wrapped on pretty-much-everything | 18:38 |
| ghostmansd | > turns out I was basically paying him to train him | 18:39 |
| ghostmansd | lol, best deal ever! | 18:39 |
| ghostmansd | It's a deal, it's a steal, it's the sale of the fucking century! | 18:40 |
| ghostmansd | Sorry markos, I could not resist to recall this Lock, Stock and Two Smoking Barrels quote | 18:42 |
| ghostmansd | https://www.youtube.com/watch?v=zxkfG7D42C8 | 18:43 |
| markos | is it a TV series or a movie? looks funny | 18:45 |
| lkcl | it's a film. | 18:46 |
| lkcl | if you can, get the uncensored version | 18:46 |
| lkcl | there were a *lot* of complaints about some of the scenes. | 18:46 |
| lkcl | i watched the original at the cinema | 18:46 |
| markos | I always get the uncensored versions anyway | 18:46 |
| markos | seems like the censored are mostly for the US anyway right? | 18:47 |
| lkcl | the original had a greyhound-hare chase | 18:47 |
| lkcl | nooo, this was a hare being killed by a greyhound | 18:47 |
| markos | ah, a real chase? | 18:47 |
| lkcl | yes | 18:47 |
| markos | oh that's a first | 18:47 |
| lkcl | it was absolutely astounding slow-motion filming | 18:48 |
| markos | so not possible to claim "no animals were harmed during filming" | 18:48 |
| lkcl | nnope | 18:48 |
| markos | I can imagine the outrage | 18:48 |
| lkcl | and denial of reality, yes... | 18:48 |
| markos | and not accidental, ie like in a documentary or just happened to get into the camera FOV while we were filming :) | 18:49 |
| markos | "we were just filming this scene your honour and the f'cking hare just came out of nowhere and Bob's greyhound went berzerk and started the chase!" | 18:50 |
| lkcl | i can't find an original cinematic version of galaxy quest, either | 18:52 |
| lkcl | sigourney weaver *actually* said "well f*** that!!" - which was overdubbed :) | 18:52 |
| lkcl | if you look carefully and try lip-reading, you can tell what she was really saying :) | 18:53 |
| * lkcl found what i was looking for, had to use write(STDOUT_FILENO) instead | 18:54 | |
| lkcl | i want a systemcall write() | 18:54 |
| *** jab <jab!~jab@user/jab> has joined #libre-soc | 19:14 | |
| *** jab <jab!~jab@user/jab> has quit IRC | 19:42 | |
| *** jab <jab!~jab@user/jab> has joined #libre-soc | 20:04 | |
| ghostmansd | Sorry folks, I committed some patches into master which were not ready yet. Should be fine now, but, please, let me know if you have issues. | 20:15 |
| *** octavius <octavius!~octavius@249.147.93.209.dyn.plus.net> has joined #libre-soc | 20:26 | |
| lkcl | ghostmansd, whoopsie, unit-test-running time | 20:43 |
| programmerjake | well, turns out ghostmansd's latest commit left nothing new broken: | 21:03 |
| programmerjake | FAILED src/openpower/sv/trans/test_pysvp64dis.py::SVSTATETestCase::test_26_sv_stq_vector_name | 21:03 |
| programmerjake | FAILED src/openpower/sv/trans/test_pysvp64dis.py::SVSTATETestCase::test_4_sv_crand | 21:03 |
| ghostmansd | These failed before | 21:03 |
| ghostmansd | so relief! | 21:03 |
| ghostmansd | thanks programmerjake! | 21:04 |
| programmerjake | = 2 failed, 336 passed, 75 skipped, 19 xfailed, 748 warnings in 1793.30s (0:29:53) = | 21:04 |
| programmerjake | ci did all the hard work: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3378258 | 21:05 |
| programmerjake | lkcl, since stdup is supposed to be post-increment, you need to revert the MEM(EA, 8) argument back to ea | 21:11 |
| *** octavius <octavius!~octavius@249.147.93.209.dyn.plus.net> has quit IRC | 21:27 | |
| lkcl | programmerjake, ermermerm... that's a rebase error. good catch | 21:36 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!