Wednesday, 2022-09-07

*** octavius_ <octavius_!> has quit IRC00:29
*** yambo <yambo!~yambo@> has quit IRC01:16
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC01:23
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC01:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:43
*** yambo <yambo!~yambo@> has joined #libre-soc01:45
*** yambo <yambo!~yambo@> has quit IRC01:52
*** yambo <yambo!~yambo@> has joined #libre-soc02:06
*** yambo <yambo!~yambo@> has quit IRC02:19
*** yambo <yambo!~yambo@> has joined #libre-soc02:32
* sadoon[m] uploaded an image: (173KiB) < >07:23
sadoon[m]I cannot believe it, finally a script that might work!07:24
sadoon[m]of course I won't let it build 0ad but that's another thing07:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC07:41
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:47
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC07:47
*** toshywoshy <toshywoshy!> has quit IRC07:47
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC07:47
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC07:47
*** mx08 <mx08!~mx08@user/mx08> has quit IRC07:47
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC07:47
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC07:47
*** midnight <midnight!~midnight@user/midnight> has quit IRC07:47
*** philpax_ <philpax_!> has quit IRC07:47
*** sauce <sauce!> has quit IRC07:47
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc07:50
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC07:52
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC07:52
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC07:52
*** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC07:52
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC07:54
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC07:54
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:56
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:56
*** sauce <sauce!> has joined #libre-soc07:58
*** philpax_ <philpax_!> has joined #libre-soc07:58
*** midnight <midnight!~midnight@user/midnight> has joined #libre-soc07:58
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc07:58
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc07:58
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc07:58
*** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc07:58
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc07:58
*** toshywoshy <toshywoshy!> has joined #libre-soc07:58
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc07:58
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc08:27
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc09:38
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc09:39
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc09:58
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc10:48
*** ghostmansd <ghostmansd!> has quit IRC10:59
lkclghostmansd[m], running unit tests now for rebase of dis-branch11:04
ghostmansd[m]Cool, thank you!11:06
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC11:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:11
lkcl some advice on formatting for debug of extra2/3.11:13
lkclyou should be able to use the NNNN{0} notation established in target_addr to indicate bits which are definitely zero (hard-coded)11:14
lkclwhich kicks in on EXTRA2 with GPR and FPR11:14
lkcland definitely kicks in on *both* CR-EXTRA2 and CR-EXTRA3.11:14
lkcl3-bits for CR fields, 2 from EXTRA3, that's going to be11:15
lkcl* scalar-EXTRA3 {00}MMnnn11:15
lkcl* vector-EXTRA3 MMnn{00}11:15
lkcl3-bits for CR fields, *1* from EXTRA2, that's going to be11:16
lkcl* scalar-EXTRA2 {000}Mnnn11:16
lkcl* vector-EXTRA2 Mnnn{00}11:16
lkcl* vector-EXTRA3 MMnnn{00} - nnn is the 3-bit CR field, MM is 2-bits from EXTRA311:16
ghostmansd[m]Fair enough, I'll think how to do it better11:35
ghostmansd[m]Operand naming will be tricky a bit, for target_addr; but for sure doable11:37
programmerjakelkcl: finally watching your video on scalable vectors...notes so far: there is no such thing as avx128 or avx25611:47
programmerjakebasically it goes x86-32 sse (adds 8 128-bit regs), sse2 (new ops only), x86_64 (extends to 16 128-bit regs), sse3 ssse3 sse4 sse4.1 sse4.2 (new ops only), avx (extends regs to 256-bit), avx2 (new ops only), avx512 (extends to 32 512-bit regs)11:50
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc11:55
programmerjakenote x86 does multi-issue execution of simd ops too, e.g. amd's zen 2 has iirc 4 256-bit alus11:56
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC12:11
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc12:12
*** octavius <octavius!> has joined #libre-soc12:14
programmerjakeother than the above errors, the video looks good! (though imho the videos should be edited to remove all the uhhs and ummms, it likely makes it easier to understand)12:28
*** ghostmansd <ghostmansd!> has joined #libre-soc13:01
lkclprogrammerjake, yeah i get flustered during ad-lib speaking like that, covering so many complex topics, i can't recall everything at once.13:15
lkcland it's intended as a one-off video, i'm annoyed that i had to spend time on it at all. i can't explain publicly why13:16
lkclghostmansd, master rebased13:17
ghostmansdCool! Thank you!13:17
ghostmansdAnd I almost finished prints for target_addr.13:17
programmerjakelkcl: k. for editing i meant mostly stuff intended as important presentations, e.g. xdc202113:21
programmerjakeit also allows you to cover more content in the allotted time13:22
programmerjakeor fosdem13:23
lkclyeah i'm thinking about it. by that time i'd likely have a much better summary. "synthesis" is the word i'm searching for13:24
lkclghostmansd, awesome.13:24
lkcli raised the issue of the inverse-mapping (BD=target_addr>>2) with the OPF ISA WG13:25
lkclprogrammerjake, regarding - if the NGI Discovery Grant is still running then in theory that and others could go under it13:26
lkclah - it isn't
programmerjake#922 is just reassigning the funds you already assigned to #794 since you closed #794 when it was only half done13:28
programmerjakesplitting out utf-8 validation as a completed subtask13:29
lkclit won't receive funding assignment and should not be added as a subtask13:30
lkclnor be added to the Vulkan NLnet MoU13:30
lkcli had to request specific authorisation from michiel to have the Vulkan MoU modified13:31
programmerjakeyou added #794...i just moved the funds to a more appropriate location13:31
lkcl#922 is *not* an authorised task13:31
lkclyou cannot do that sort of thing13:31
lkclplease put all of the funds back13:31
lkcland remove #922 as a sub-task of #794.13:32
lkcli am right in the middle of negotiations with Michiel and if he looks at this, when he has time, he will think that i cannot give him accurate task-lists13:33
lkcland may DENY - or delay - the authorisation of the budget reallocation.13:33
programmerjakeumm, what specifically did michiel authorize? funding utf-8 validation or funding #794 specifically?13:33
lkclplease put it back - urgently13:33
programmerjakewould it work to add a note to the top comment pointing to the correct location and explaining what happened?13:34
lkclprogrammerjake, you're not listening. again.13:34
lkcldon't bother. i'll sort it out.13:35
programmerjakei am listening i just think maybe there's a better route than having to move all stuff related to utf-8/16 conversion out of #794 because otherwise #794 is only 1/2 or 1/3 done and shouldn't be marked resolved fixed13:37
programmerjakeso i'm asking before picking which route13:37
programmerjakelkcl ^13:38
lkcli've already sent Michiel a list of tasks which he will be entering into the back-end database.13:38
lkclthat was a fuck of a lot of work and i went to a lot of trouble to keep it as simple as possible for him, to minimise time13:38
lkclby not consulting me BEFORE making unauthorised changes to the tasks you are interfering with that13:38
programmerjakeok, so he authorized #794 specifically13:39
lkclcausing me to do more work13:39
lkclcausing Michiel to get confused13:39
lkcldelaying the project during a critical deadline period13:39
lkclpossibly causing us to lose funding13:39
lkclcausing me to not be able to focus on completing tasks before the deadline13:40
lkclno, he has *not* authorised #794 specifically yet13:40
lkcli haven't had a response back from him13:40
programmerjakelkcl, just leave #922 alone, i'll remove budget and morph it into utf8/16 conversion13:40
lkcli've already done it because you didn't understand, didn't ask, and Michiel could perform his evaluation at any time13:41
programmerjake#794 can be morphed to only cover utf-8 validation13:41
lkclyou should not have interfered here.13:41
programmerjakewell, i did ask, several days ago:
lkclthese tasks now *have* to strictly match with the NLnet system13:42
programmerjakesince you never responded i assumed nothing was happening13:42
lkclwe risk getting audited and losing funding if there's anything amiss13:42
lkclyou *cannot* make arbitrary decisions based on ASSUMPTIONS13:42
lkclif you don't receive a response it means i missed it or was too busy13:43
programmerjakelkcl: important info that should have been conveyed when you found out, not now when i tried to change stuff13:43
lkclyou shouldn't fucking well have been changing anything AT ALL13:43
programmerjakeno, that wasn't the case before...13:44
lkclyou are not the Project Administrator, you don't have the authority nor the direct responsibility to ensure that EU Audits are accurate13:44
programmerjakenothing had been paid yet...13:44
lkcli cannot go into a public explanation here13:45
lkclsub-sub-task allocation of budgets is not something we can do arbitrarily any more13:45
lkcli cannot explain publicly why.13:45
lkclit has to do with the fact that everything is now mirror-recorded in NLnet's new system13:46
lkclwhich is presented to the EU Auditors, directly.13:46
programmerjakeok. please post that on the mailing list so others don't make the same mistake i unknowingly did13:46
lkclno, i am not going to do that.13:47
lkcland please do not make such a post either13:48
lkcli do not want alerts and questions going out.13:48
programmerjakeok, that's just going to cause problems tho13:48
programmerjakedo you care if stuff gets assigned/unassigned to the future milestone? i mostly use it as a way to keep track of stuff that should get paid but we don't have any funding assigned13:52
lkclreally really please DON'T fuck around with the database of payments13:52
lkclit's extremely serious consequences13:52
programmerjakedoes that cover the future milestone?13:53
lkclfuture work doesn't have budgets, and is not covered by EU Auditors, so it's not a problem.13:53
programmerjakei edited the top comments to explain what happened so people reading it aren't confused14:01
programmerjakewell, gn all. see you at the wed meeting14:03
*** ghostmansd <ghostmansd!> has quit IRC14:06
lkcli've removed those comments and returned them to the original so that Michiel is *not* confused by additional history that he does not need to know anything about when performing the evaluation14:08
lkclit's crucially important to keep the amount of work that Michiel needs to do to a bare minimum.14:09
lkclthey've had one long-term employee leave and need more staff, but are also taking on more work14:09
lkclghostmansd[m], are those examples vector or scalar?14:10
programmerjakeuuh, it's more work for michiel if he sees a bunch of comments talking about stuff other than utf-8 validation, imho reading a 1 sentence note explaining the title change is waay easier14:10
ghostmansd[m]Hm, this should be clear from the first disasm line...14:10
lkclprogrammerjake, please leave it alone14:10
ghostmansd[m]Should I explicitly put info about vector: false in verbose mode perhaps?14:11
lkclghostmansd[m], you mean if it doesn't have "*" in the operand?14:11
programmerjakealso michiel's not looking at #922 so why change that too?!14:11
ghostmansd[m]If these were vector, there would have been asterisks... but I haven't checked it yet.14:11
lkcli think so, yes.14:11
ghostmansd[m]OK I'll update14:12
ghostmansd[m]And check vectors14:12
ghostmansd[m]I added some code there but haven't checked it yet :-)14:12
lkclexplicitly spelling it out with the word "scalar" or "vector" on these line extra3[2]14:12
ghostmansd[m]A-ha, got you14:12
lkclthe bit-ordering is currently inverted, then14:12
lkclthe EXTRA2/3 bits go at the *front* for scalar (in the MSBs) for scalar14:13
ghostmansd[m]Fucking MSB14:13
lkcli know...14:13
ghostmansd[m]I knew I would fail there :-D14:13
ghostmansd[m]Ok, this is actually simple to change14:13
lkclit's the engineering rule "know what results you're looking for"14:14
programmerjakehaving #922 reference #794 where all the discussion happened is imho waay more important than the off chance that michiel will look at #922, it has no funding so he would immediately ignore it14:15
lkclprogrammerjake, i said: please leave it.  second time of repeating14:15
programmerjakeok, i'll leave it, but imho it's a stupid choice for #92214:17
lkcli'll deal with it and take responsibility for communicating with Michiel. that's my role.14:18
*** ghostmansd <ghostmansd!> has joined #libre-soc14:42
ghostmansdlkcl, am I right that `sv.lwzu *1,16(63)` is illegal?15:20
ghostmansdBut somehow `sv.lwzu *2,16(63)` is valid...15:21
ghostmansdI've been under impression that we cut the range, not change the step.15:21
ghostmansd*0 valid; *1 invalid; *2 valid; and so on.15:21
ghostmansdOr do we extend the range for scalars, and change range for vectors?15:22
programmerjakeyeah afaict sv.lwzu *1, ... is illegal15:27
programmerjakesv.lwzu 1, ... is legal, but sv.lwzu 64, ... is not15:27
programmerjakeextra2 vector gprs/fprs have step 2, extra2 scalar gprs/fprs just go up to r6315:29
ghostmansdA question from noob: why accessing vector register 1 is illegal?15:31
ghostmansdEven `sv.lwzu *126,16(63)` is legal.15:32
ghostmansdUnsurprisingly from what you tell, but surprisingly generally. Or I simply misunderstand the way vector registers are intended to work.15:33
ghostmansdWhy odd registers are banned?15:34
programmerjakebasically because we don't have enough spare bits to address all 7 bits in the register address, so we need to decide where to insert a zero bit, for vectors we insert it in the lsb, for scalars in the msb15:35
ghostmansdAh well pysvp64asm even doesn't give a shit about this: `sv.lwzu *666,16(63)`15:35
ghostmansdYes, exactly, that's the question, actually: why not LSB?15:36
ghostmansdThanks for putting it clearly. :-)15:36
programmerjakebecause scalars need to access all existing powerisa registers and a lot of them are odd, e.g. r1 which is the stack pointer, or r3 which is the first arg reg15:37
programmerjakevectors can get away with every other reg because we can assume they will usually use at 128-bits worth of registers15:38
programmerjakeand we usually need lots of space just for vectors, not scalars15:38
ghostmansdBut we won't be able to use 128-bits worth of registers on EXTRA215:38
ghostmansdI mean, we end up with 64 values anyway...15:39
programmerjakesv.lwzu *4, ... can load r4, r5, r6, r7, ...15:39
programmerjakeso not being able to start at r5 is less of an issue15:40
programmerjakethere's remap offset if we really need to15:40
ghostmansdOK I begin to understand15:40
ghostmansdBut still perhaps I need somewhat good intro on vectors in general15:41
ghostmansd(perhaps not libresoc-specific, but rather in general)15:41
programmerjakelkcl, can i let you do that, i need to sleep15:41
ghostmansdah right, totally forgot about the time diff15:41
ghostmansdsorry :-)15:41
ghostmansdsure, gn! thanks for tips!15:41
programmerjakeit's nearly 8am here, i stayed up waay too late...ttyl15:43
lkclghostmansd, if you study any other vector ISA you'll find it doesn't help because they have a totally different paradigm16:09
lkclother vector ISAs such as Cray have *actual* vector register files16:10
lkclvr0: [element 0, element 1, element 2,..... element 1000]16:10
lkclvr1: [element 0, element 1, element 2,..... element 1000]16:10
ghostmansdwhat does this do? field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE)16:12
lkclthis how it works in Simple-V:
ghostmansdI have an issue with MSB in vector/scalar16:12
ghostmansdAnd cannot get the order16:12
lkclthat's the equivalent of FieldSelectableInt16:12
ghostmansdwhat specific operation?16:13
lkclit's a complete overkill way of returning spec[SPECb.LSB] concatenated with spec[SPECb.MSB]16:13
ghostmansdAha, so it's concat16:13
lkclyes but in inverted-bit-order16:14
ghostmansdwhy not Cat?16:14
lkclbecause we wanted to keep the information about the MSB0 numbering in there16:14
ghostmansdOK. Say I have some extra2, and I have this: vector = extra2[0]; value_bit = extra2[1].16:16
ghostmansdDepending on what vector equals to, what should I do with value_bit?16:16
ghostmansdif vector, I should shift up, so it ends up in MSB of 2-bit value?16:17
ghostmansdif not, I place it in LSB?16:17
lkclagain: that pseudocode16:17
lkclno. other way round16:17
ghostmansd# Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2]16:17
lkclremember MSB0-ordering bollocks16:17
ghostmansdFuck it's so fucking annoying16:18
ghostmansdWasting two hours for just putting this damn bit into the correct index and concatenating it.16:18
lkcli know...16:18
ghostmansdOK, again16:18
ghostmansdlet's just do it for these two bits16:18
ghostmansdI have bool(vector) and some damn bit16:19
ghostmansdWhat should I do?16:19
ghostmansdSimply give me the instruction, too tired to even think about this in MSB0 terms.16:19
lkclon phone16:19
lkclrelax :)16:19
ghostmansd(consider just only this vector and this bit)16:20
ghostmansdI will adopt the suffix operand with it later16:20
ghostmansdJust "an exhaustive guide which two bits you should finally have depending on `if vector: XXX; else: YYY"16:20
ghostmansd[m]Please also express these in SelectableInt if possible16:26
ghostmansdOr well, no. Let's use plain integers.16:34
ghostmansdJust assume I have bool(extra2[extra_idx][0]) and int(extra2[extra_idx][1])16:34
lkclok am back16:35
lkcllet's set isvec=bool(extra2[extra_idx][0])16:35
lkclit's then:16:35
lkclif isvec:16:35
lkcl    return RA<<2 | int(extra2[extra_idx][1]) << 116:36
lkcl    return RA<<2 | int(extra2[extra_idx][1]) <<516:36
lkcl    return RA | int(extra2[extra_idx][1]) << 516:36
ghostmansdHow comes RA not in the end?16:39
ghostmansdRA goes first for vectors, for scalars shouldn't it be in the end16:40
ghostmansdOK got it16:40
ghostmansdFuck that's not concatenation it's logical OR16:40
lkcl*RA* gets shifted for vectors and... yes.16:40
ghostmansdSo stressed. I'll make this stuff work and then take a break.16:40
ghostmansdOK so here's the problem I had: I shifted extra2[extra_idx][1] by 1 unconditionally.16:42
lkcli see that -                     extra = (int(extra[1]) << 1)16:42
lkcli think this is a reason why i did a conversion to an intermediate variable, "spec"16:43
lkclbut i see you are doing the same thing, just calling it still "extra"16:43
ghostmansdYes but I do it regardless of vector mode16:43
ghostmansdThis is the problem16:44
ghostmansdI _always_ shifted by 116:44
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC16:47
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc16:48
lkclyep i can confirm i just put sv.lwzu 62,16(47) into pysvp64asm and got .long 0x05401500;16:48
lkclwhich matches with pysvp64dis16:49
lkcl00 15 40 05    sv.lwzu r62,16,r4716:49
lkclthat's after taking out the shift-by-one16:50
lkclnow, i must apologise, you'll have to experiment with EXTRA3.16:51
lkclthe existing code *MIGHT* be correct16:51
lkcl                if record.etype is _SVEtype.EXTRA3:16:51
lkcl                    extra_span = tuple(map(str, extra_span))16:51
lkcl                    extra = int(extra[1, 2])16:51
lkclbut it MIGHT be16:51
ghostmansdOK seems the task is done16:51
lkclerrmmm... thinking....16:52
ghostmansdI'll post it soon16:52
lkcl                    extra = int(extra[1]) << 1 | int(extra[2])16:52
lkclok cool16:52
ghostmansdI mean some examples16:52
lkcli will try some as well16:53
lkcli'll work it out16:53
lkclyou clearly need a break :)16:53
lkclah i spotted this16:53
lkcl    RA16:53
lkcl        010111116:53
lkcl        23, {0}, 43, 44, 45, 46, 4716:53
lkclthat should be {0}, 23, 43, ....16:53
lkcli can sort that out16:53
ghostmansdJust noticed that16:54
lkcl                    extra_span = (extra_span + ("{0}",))16:54
lkclshould be16:54
lkcl                    extra_span = (("{0}",) + extra_span)16:54
lkclreal easy. want me to do it?16:54
*** tplaten <tplaten!> has joined #libre-soc16:55
ghostmansdthis is what I just did16:55
lkcldoh :)16:55
ghostmansdnow to immediates16:55
ghostmansdI don't like how it looks (that we have to bookkeep whether the previous stuff was immediate) but I don't know how to do better16:55
lkclyes it should be sv.lwzu r62,16(r47) btw16:56
ghostmansdwe already applied this cheat for immortability in spec16:56
ghostmansdso I guess it won't hurt to cheat more16:56
* lkcl snorts16:56
ghostmansd(yeah this should have been a function)16:56
lkclHA! cool! extra2 vector works!17:04
lkclok let's try an EXTRA3.  an sv.add.17:08
lkclHA! even cooler - EXTRA3 vector works too17:12
lkclso that _is_ the right way round (in the spec page)17:14
ghostmansdyeah, I wouldn't still call it clear there :-)17:15
* lkcl snorts17:15
ghostmansdbut OK, perhaps only MSB0 confuses me17:15
lkclyou and both of me both17:15
lkcl18 months before i caught myself thinking naturally in MSB0 ordering.  something to do with reading digits from left to right just went "click".17:16
ghostmansdI fixed immediates17:17
ghostmansdreally success story today17:17
ghostmansd00 25 40 05    lwzu *r0,16(r63)17:18
ghostmansd10 00 1f 8417:18
ghostmansdI moved it to common class, because operands do alredy check insn type (SVP64 or not)17:18
lkclecho -n -e '\x00\x3a\x40\x05\x10\x00\xec\x85' | pysvp64dis -v17:19
lkcl00 3a 40 05    lwzu *r62,16(*r48)17:19
lkcl10 00 ec 8517:19
ghostmansdYeah that's a cheat17:19
ghostmansdjoyful grunting17:19
lkcl    spec17:19
lkcl        sv.lwzu r10,14848(r0)17:19
ghostmansdWow :-)17:19
ghostmansdMissed that17:19
lkcl14848? moo? :)17:19
ghostmansdno idea17:19
ghostmansdalso for r1017:20
ghostmansdfuck, should've used name there, not value17:20
ghostmansdcopy & paste17:21
lkcldoh :)17:21
lkcl    spec17:21
lkcl        sv.add RT,RA,RB (OE=0 Rc=0)17:21
lkclchanged to random-numbers-etc.17:21
lkcland missing "sv." in front...17:21
ghostmansdyeah it gets the value lol17:21
lkcl00 3a 40 05    >>>sv.<<<lwzu *r62,16(*r48)17:21
ghostmansdoo good catch17:22
ghostmansd1 sec17:22
ghostmansdI haven't even started printing all fields yet!17:22
lkclwell if this turns into a bottomless pit we truncate it ok?17:23
lkcltask equals defined as success17:23
ghostmansdOK another take17:27
ghostmansdit's already the bottomless pit lol17:27
ghostmansdany time I return to this task I always find there's something left17:28
ghostmansdanyway, if we really won extras, this is already sufficient reason to switch binutils to this code17:28
ghostmansdin binutils, this was AWFUL17:28
ghostmansdand also I recently found that EXTRA2 doesn't work there at all17:29
ghostmansd`sv.lwzu 63,16(63)` shits in my eyes with "Error: cannot remap EXTRA"17:29
ghostmansdso yeah new fields are the way to go17:30
ghostmansdideally I'd drop these if/else crap in DynamicOperandReg, but even this is better compared to what we have now17:30
ghostmansdI should've asked you about this damn bit in EXTRA2 before, really :-)17:31
ghostmansdhaving it the way you wrote explains it much better than the pseudocode17:31
ghostmansdI literally spend 2+ hours there17:31
ghostmansdso, my summary: FUCK MSB0!17:32
ghostmansdCRs will be even worse I guess17:32
ghostmansdbut perhaps bits of DynamicOperandReg can be re-used17:32
ghostmansdDo we have other tricky parts except for CRs?17:33
ghostmansdIs everything else straightforward? I'm not so sure abot specifiers, perhaps they will need more tuning, too.17:34
ghostmansdLikely will be a reverse-engineering of pysvp64asm17:34
ghostmansd[m]lkcl, FYI:
ghostmansd[m]I don't think we should fix it now, since fields fix it automatically (they check for count of bits upon assignment)18:00
lkclCRs are not that bad (he said, ha ha)18:10
lkclbut you have to remember one other thing18:10
lkclfirstly, the easy part18:10
lkclthose shift amounts "RA<<2 | extra" and "extra<<5 | RA" have to be adapted to 3-bit18:11
*** octavius <octavius!> has quit IRC18:11
lkcl"CRf << 4 | extra<<2" for EXTRA3 vector and "extra2<<5 | CRf<<2" for scalar, something like that18:12
lkcl(basically look at the table in the spec)18:12
lkclbut that's 3-bit *fields*18:12
lkclthere are also *FIVE* bit CR-accessers18:13
lkcl(because the CR *Register* is a 32-bit quantity, comprising 8 fields of 2-bits each)18:13
lkclso for the *FIVE* bit accessors you must first strip out the top THREE bits (containing the 3-bit CR *FIELD* number)18:13
lkclthen go through the 3-bit procedure18:13
lkclthen SHIFT THAT UP BY TWO and drop in the 2-bits of e.g. BA/BO18:14
tplatenMy talk "Using the Libre-SOC for building a mobile VR headset" at the "X.Org developer's Conference + WineConf + FOSS XR 2022" has been accepted.18:14
lkclwhilst all the time remembering that the access is all in MSB0 numbering.18:15
lkcltplaten, brilliant!18:15
lkcldo put it on the conferences page
lkclbut, now that you have GPR/FPR working, you can compare against the GPR/FPR tables18:16
lkclat least now go "bloody hell that was so much simpler now it's implemented, i actually recognise those tables now"18:17
lkcland from there comparatively-deduce the above logic, for CRs.18:17
tplatenI'll do this weekend18:19
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC18:20
tplatenI will also participate at
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc18:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc18:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:32
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:32
ghostmansd[m]Ok will check tomorrow18:39
ghostmansd[m]Extras drained all the powers today :-)18:39
sadoon[m]lkcl:  when do you need debian working?18:47
sadoon[m]context: I could hurry the process but pbuild is so frustrating that I'm overhauling their "buildd" script to support sbuild instead, it works excellently so far but the last thing I need to do is force it to keep caches of apt packages so that it doesn't have to download them again every time19:00
sadoon[m]Which ironically is a feature pbuild already has but sbuild doesn't seem to19:00
sadoon[m]otherwise you could say the script is 95% done and all I need to do after is run it once for main and once again for security and then subsequently say weekly for all the updates19:01
sadoon[m]then it's a matter of toying with gcc and clang to force them to build ppc64le without any vector extensions19:01
sadoon[m]Hell I've even gotten the hang of signing packages so basically this apt package caching thing is the only thing left, I'm considering also keeping a local archive19:02
sadoon[m]I'm also building everything in RAM which is a major speedup, things are looking really good so far19:05
lkclsadoon[m], you can kiinda install a transparent apt-proxy-cache and point at that instead of the direct thing19:16
lkcldo you have ccache also installed?19:16
lkclmight help speed things up too19:16
lkclparticularly given that 95% of debian packages are "reproducible build" now19:17
sadoon[m]ccache is worrying because we want clean builds19:17
lkclthere's no particular rush on this19:17
lkclccache _does_ give clean builds19:17
lkcli've never seen it fail in 20 years of using it19:18
sadoon[m]i'll look into apt-proxy-cache19:18
sadoon[m]oh nice19:18
sadoon[m]definitely then19:18
lkclit's extremely clever19:18
sadoon[m]both of them I guess19:18
sadoon[m]I'll need a beefier SSD to fit everything and that's it19:18
lkclbasically it understands the full syntax of gcc and clang19:18
lkclthen performs a "gcc -E"19:19
lkclcombines the output of that with the full command-line options19:19
lkclperforms a hash19:19
lkcland uses that as the lookup.19:19
sadoon[m]Apparently I already have an archive of the debian march 2021 snapshot on my server, just doing an apt-mirror now to check that it was fully downloaded :D19:19
sadoon[m]lkcl: very cool, will integrate it then19:19
lkclif the *entire* output from "gcc -E" and the command-line options are identical, you *know* that the rsults are going to be the same19:19
lkclit saves absolutely vast amounts of time if repeating a build.19:20
sadoon[m]I also think you'll be happy to know we do have a somewhat usable web browser on ppc even with webkit :)19:20
lkclpffh *snort*19:20
sadoon[m]so this is not just a basic linux environment19:20
sadoon[m]hey I mean at least it helps my g4 and g5 machines right?19:21
sadoon[m]I can actually get on gitlab and stuff19:21
lkclholy cow19:21
sadoon[m]strange, apt-mirror wants to download 69 gigabytes even though I see all the packages inside..19:22
lkclthat's apt-mirror19:23
lkclthat's literally mirroring the entire distro19:23
lkclall 40,000 packages if you're using testing19:23
sadoon[m]yes but it continues when it sees you already have files downloaded19:23
sadoon[m]I think I messed up the directory19:23
lkclyou probably want
sadoon[m]No I do want apt-mirror actually because these files will be useful later for other things19:24
sadoon[m]And I also want to mirror many older releases of ubuntu and debian for.. reasons :P19:25
sadoon[m]two birds one stone19:25
lkclha, there you go19:25
sadoon[m]My ppc64 directory is already 70 gigabytes.. this is strange.19:25
sadoon[m]I'll assume apt-mirror is messing up and try using it now19:26
sadoon[m]By it I mean the local archive19:26
lkclyou can't "totally" mess up because of digital signatures.19:26
lkclbear in mind19:26
lkclthat depending on the time, if you are doing testing, security, updates or backports19:27
lkclyou *can* end up catching things right in the middle of an update19:27
lkcland have half the packages downloaded but the other half are gone because they were replaced with newer versions19:27
lkclif your ***ISP*** has a transparent cacheing proxy on the front with fucked-up timeouts, it gets even worse19:28
sadoon[m]that's normally the case but remember that I'm downloading a sid snapshot from March 202119:28
sadoon[m]And we're going to rebuild everything from scratch targeting bullseye anyways19:28
lkclbullseye should not change, as long as you don't also try to include security updates, volatile, or bullseye-updates or backports19:29
sadoon[m]what I have as a mirror is sid when bullseye was frozen19:30
sadoon[m]Which is enough to build bullseye completely :D19:30
sadoon[m]For a while I treated it as if it were bullseye on my g4 and g5 machines and manually built the security updates with rss feeds19:31
sadoon[m]It was hell19:31
sadoon[m]But it was a theory and it worked19:31
sadoon[m]apt is not liking my sshfs mounted mirror.. permission issues19:46
sadoon[m]the vm does not have direct access to the server so I have to find another solution19:47
*** octavius <octavius!> has joined #libre-soc19:48
*** ghostmansd <ghostmansd!> has quit IRC20:15
*** tplaten <tplaten!> has quit IRC20:46
*** ghostmansd <ghostmansd!> has joined #libre-soc20:54
*** ghostmansd <ghostmansd!> has quit IRC21:01
programmerjakein theory mounting a ext4 filesystem on a file in a sshfs mounted directory should work...21:17
programmerjakeshould fix permission issues21:17
openpowerbot[irc] <toshywoshy> ping meeting LibreSOC22:03
octaviusprogrammerjake, markos, sadoon, meeting22:03
programmerjakelkcl: jitsi bugged out again, there's like 48 fptrans ops22:35
programmerjakelkcl: the set of remaps allowed in svp64 compliancy levels should be updated, e.g. indexed and offset imho should be supported at the lower level, since those things are replacing existing instructions in other vector/simd isas22:59
programmerjakelower levels*23:00
*** markos <markos!~Konstanti@> has quit IRC23:01
programmerjakestuff like fft and matrix can reasonably be left for the upper levels23:01
*** octavius <octavius!> has quit IRC23:08

Generated by 2.17.1 by Marius Gedminas - find it at!