| *** octavius_ <octavius_!~octavius@238.147.93.209.dyn.plus.net> has quit IRC | 00:29 | |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 01:16 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:23 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:24 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:43 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:43 | |
| *** yambo <yambo!~yambo@69.146.1.110> has joined #libre-soc | 01:45 | |
| *** yambo <yambo!~yambo@69.146.1.110> has quit IRC | 01:52 | |
| *** yambo <yambo!~yambo@69.146.1.110> has joined #libre-soc | 02:06 | |
| *** yambo <yambo!~yambo@69.146.1.110> has quit IRC | 02:19 | |
| *** yambo <yambo!~yambo@69.146.1.110> has joined #libre-soc | 02:32 | |
| * sadoon[m] uploaded an image: (173KiB) < https://libera.ems.host/_matrix/media/r0/download/unredacted.org/CDgTAZhsuyNTteVdwWsvMdmX/image.png > | 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 thing | 07:24 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:47 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 07:47 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 07:47 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 07:47 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has quit IRC | 07:47 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 07:47 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC | 07:47 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 07:47 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 07:47 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has quit IRC | 07:47 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has quit IRC | 07:47 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:50 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 07:52 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 07:52 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 07:52 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC | 07:52 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 07:54 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 07:54 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:56 | |
| *** sauce <sauce!~sauce@omae.wa.mou.shindei.ru> has joined #libre-soc | 07:58 | |
| *** philpax_ <philpax_!sid516926@id-516926.lymington.irccloud.com> has joined #libre-soc | 07:58 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 07:58 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 07:58 | |
| *** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc | 07:58 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 07:58 | |
| *** alethkit <alethkit!23bd17ddc6@2604:bf00:561:2000::3ce> has joined #libre-soc | 07:58 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 07:58 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 07:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:58 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 08:27 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 09:38 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 09:39 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 09:58 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 10:48 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 10:59 | |
| lkcl | ghostmansd[m], running unit tests now for rebase of dis-branch | 11:04 |
| ghostmansd[m] | Cool, thank you! | 11:06 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.133> has joined #libre-soc | 11:11 | |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=917#c8 some advice on formatting for debug of extra2/3. | 11:13 |
| lkcl | you should be able to use the NNNN{0} notation established in target_addr to indicate bits which are definitely zero (hard-coded) | 11:14 |
| lkcl | which kicks in on EXTRA2 with GPR and FPR | 11:14 |
| lkcl | and definitely kicks in on *both* CR-EXTRA2 and CR-EXTRA3. | 11:14 |
| lkcl | 3-bits for CR fields, 2 from EXTRA3, that's going to be | 11:15 |
| lkcl | * scalar-EXTRA3 {00}MMnnn | 11:15 |
| lkcl | * vector-EXTRA3 MMnn{00} | 11:15 |
| lkcl | 3-bits for CR fields, *1* from EXTRA2, that's going to be | 11:16 |
| lkcl | * scalar-EXTRA2 {000}Mnnn | 11:16 |
| lkcl | * vector-EXTRA2 Mnnn{00} | 11:16 |
| lkcl | whoops | 11:16 |
| lkcl | * vector-EXTRA3 MMnnn{00} - nnn is the 3-bit CR field, MM is 2-bits from EXTRA3 | 11:16 |
| ghostmansd[m] | Fair enough, I'll think how to do it better | 11:35 |
| ghostmansd[m] | Operand naming will be tricky a bit, for target_addr; but for sure doable | 11:37 |
| programmerjake | lkcl: finally watching your video on scalable vectors...notes so far: there is no such thing as avx128 or avx256 | 11:47 |
| programmerjake | basically 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-soc | 11:55 | |
| programmerjake | note x86 does multi-issue execution of simd ops too, e.g. amd's zen 2 has iirc 4 256-bit alus | 11:56 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.133> has quit IRC | 12:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:12 | |
| *** octavius <octavius!~octavius@197.147.93.209.dyn.plus.net> has joined #libre-soc | 12:14 | |
| programmerjake | other 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!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:01 | |
| lkcl | programmerjake, yeah i get flustered during ad-lib speaking like that, covering so many complex topics, i can't recall everything at once. | 13:15 |
| lkcl | and 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 why | 13:16 |
| lkcl | ghostmansd, master rebased | 13:17 |
| ghostmansd | Cool! Thank you! | 13:17 |
| ghostmansd | And I almost finished prints for target_addr. | 13:17 |
| programmerjake | lkcl: k. for editing i meant mostly stuff intended as important presentations, e.g. xdc2021 | 13:21 |
| programmerjake | it also allows you to cover more content in the allotted time | 13:22 |
| programmerjake | or fosdem | 13:23 |
| lkcl | yeah i'm thinking about it. by that time i'd likely have a much better summary. "synthesis" is the word i'm searching for | 13:24 |
| lkcl | ghostmansd, awesome. | 13:24 |
| lkcl | i raised the issue of the inverse-mapping (BD=target_addr>>2) with the OPF ISA WG | 13:25 |
| lkcl | programmerjake, regarding https://bugs.libre-soc.org/show_bug.cgi?id=922 - if the NGI Discovery Grant is still running then in theory that and others could go under it | 13:26 |
| lkcl | ah - it isn't https://nlnet.nl/discovery/ | 13:26 |
| programmerjake | #922 is just reassigning the funds you already assigned to #794 since you closed #794 when it was only half done | 13:28 |
| programmerjake | splitting out utf-8 validation as a completed subtask | 13:29 |
| lkcl | it won't receive funding assignment and should not be added as a subtask | 13:30 |
| lkcl | nor be added to the Vulkan NLnet MoU | 13:30 |
| lkcl | i had to request specific authorisation from michiel to have the Vulkan MoU modified | 13:31 |
| programmerjake | you added #794...i just moved the funds to a more appropriate location | 13:31 |
| lkcl | #922 is *not* an authorised task | 13:31 |
| lkcl | you cannot do that sort of thing | 13:31 |
| lkcl | please put all of the funds back | 13:31 |
| lkcl | and remove #922 as a sub-task of #794. | 13:32 |
| lkcl | i 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-lists | 13:33 |
| lkcl | and may DENY - or delay - the authorisation of the budget reallocation. | 13:33 |
| programmerjake | umm, what specifically did michiel authorize? funding utf-8 validation or funding #794 specifically? | 13:33 |
| lkcl | please put it back - urgently | 13:33 |
| programmerjake | would it work to add a note to the top comment pointing to the correct location and explaining what happened? | 13:34 |
| lkcl | programmerjake, you're not listening. again. | 13:34 |
| lkcl | don't bother. i'll sort it out. | 13:35 |
| programmerjake | i 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 fixed | 13:37 |
| programmerjake | so i'm asking before picking which route | 13:37 |
| programmerjake | lkcl ^ | 13:38 |
| lkcl | i've already sent Michiel a list of tasks which he will be entering into the back-end database. | 13:38 |
| lkcl | that 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 time | 13:38 |
| lkcl | by not consulting me BEFORE making unauthorised changes to the tasks you are interfering with that | 13:38 |
| programmerjake | ok, so he authorized #794 specifically | 13:39 |
| lkcl | causing me to do more work | 13:39 |
| lkcl | causing Michiel to get confused | 13:39 |
| lkcl | delaying the project during a critical deadline period | 13:39 |
| lkcl | possibly causing us to lose funding | 13:39 |
| lkcl | causing me to not be able to focus on completing tasks before the deadline | 13:40 |
| lkcl | no, he has *not* authorised #794 specifically yet | 13:40 |
| lkcl | i haven't had a response back from him | 13:40 |
| programmerjake | lkcl, just leave #922 alone, i'll remove budget and morph it into utf8/16 conversion | 13:40 |
| lkcl | i've already done it because you didn't understand, didn't ask, and Michiel could perform his evaluation at any time | 13:41 |
| programmerjake | #794 can be morphed to only cover utf-8 validation | 13:41 |
| lkcl | you should not have interfered here. | 13:41 |
| programmerjake | well, i did ask, several days ago: https://bugs.libre-soc.org/show_bug.cgi?id=794#c42 | 13:42 |
| lkcl | these tasks now *have* to strictly match with the NLnet system | 13:42 |
| programmerjake | since you never responded i assumed nothing was happening | 13:42 |
| lkcl | we risk getting audited and losing funding if there's anything amiss | 13:42 |
| lkcl | you *cannot* make arbitrary decisions based on ASSUMPTIONS | 13:42 |
| lkcl | if you don't receive a response it means i missed it or was too busy | 13:43 |
| programmerjake | lkcl: important info that should have been conveyed when you found out, not now when i tried to change stuff | 13:43 |
| lkcl | you shouldn't fucking well have been changing anything AT ALL | 13:43 |
| programmerjake | no, that wasn't the case before... | 13:44 |
| lkcl | you are not the Project Administrator, you don't have the authority nor the direct responsibility to ensure that EU Audits are accurate | 13:44 |
| programmerjake | nothing had been paid yet... | 13:44 |
| lkcl | i cannot go into a public explanation here | 13:45 |
| lkcl | sub-sub-task allocation of budgets is not something we can do arbitrarily any more | 13:45 |
| lkcl | i cannot explain publicly why. | 13:45 |
| lkcl | it has to do with the fact that everything is now mirror-recorded in NLnet's new system | 13:46 |
| lkcl | which is presented to the EU Auditors, directly. | 13:46 |
| programmerjake | ok. please post that on the mailing list so others don't make the same mistake i unknowingly did | 13:46 |
| lkcl | no, i am not going to do that. | 13:47 |
| lkcl | and please do not make such a post either | 13:48 |
| lkcl | i do not want alerts and questions going out. | 13:48 |
| programmerjake | ok, that's just going to cause problems tho | 13:48 |
| programmerjake | do 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 assigned | 13:52 |
| lkcl | really really please DON'T fuck around with the database of payments | 13:52 |
| lkcl | it's extremely serious consequences | 13:52 |
| programmerjake | does that cover the future milestone? | 13:53 |
| lkcl | future work doesn't have budgets, and is not covered by EU Auditors, so it's not a problem. | 13:53 |
| programmerjake | k | 13:53 |
| programmerjake | i edited the top comments to explain what happened so people reading it aren't confused | 14:01 |
| programmerjake | well, gn all. see you at the wed meeting | 14:03 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:06 | |
| lkcl | i'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 evaluation | 14:08 |
| lkcl | it's crucially important to keep the amount of work that Michiel needs to do to a bare minimum. | 14:09 |
| lkcl | they've had one long-term employee leave and need more staff, but are also taking on more work | 14:09 |
| lkcl | ghostmansd[m], are those examples vector or scalar? | 14:10 |
| ghostmansd[m] | scalars | 14:10 |
| programmerjake | uuh, 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 easier | 14:10 |
| ghostmansd[m] | Hm, this should be clear from the first disasm line... | 14:10 |
| lkcl | programmerjake, please leave it alone | 14:10 |
| ghostmansd[m] | Should I explicitly put info about vector: false in verbose mode perhaps? | 14:11 |
| lkcl | ghostmansd[m], you mean if it doesn't have "*" in the operand? | 14:11 |
| programmerjake | also 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 |
| ghostmansd[m] | Yeah | 14:11 |
| lkcl | i think so, yes. | 14:11 |
| ghostmansd[m] | OK I'll update | 14:12 |
| ghostmansd[m] | And check vectors | 14:12 |
| ghostmansd[m] | I added some code there but haven't checked it yet :-) | 14:12 |
| lkcl | explicitly spelling it out with the word "scalar" or "vector" on these line extra3[2] | 14:12 |
| ghostmansd[m] | A-ha, got you | 14:12 |
| lkcl | the bit-ordering is currently inverted, then | 14:12 |
| lkcl | the EXTRA2/3 bits go at the *front* for scalar (in the MSBs) for scalar | 14:13 |
| ghostmansd[m] | Fucking MSB | 14:13 |
| ghostmansd[m] | Sigh | 14:13 |
| lkcl | i know... | 14:13 |
| ghostmansd[m] | I knew I would fail there :-D | 14:13 |
| ghostmansd[m] | Ok, this is actually simple to change | 14:13 |
| lkcl | it's the engineering rule "know what results you're looking for" | 14:14 |
| programmerjake | having #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 it | 14:15 |
| lkcl | programmerjake, i said: please leave it. second time of repeating | 14:15 |
| programmerjake | ok, i'll leave it, but imho it's a stupid choice for #922 | 14:17 |
| lkcl | i'll deal with it and take responsibility for communicating with Michiel. that's my role. | 14:18 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 14:42 | |
| ghostmansd | lkcl, am I right that `sv.lwzu *1,16(63)` is illegal? | 15:20 |
| ghostmansd | But somehow `sv.lwzu *2,16(63)` is valid... | 15:21 |
| ghostmansd | I'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 |
| ghostmansd | Or do we extend the range for scalars, and change range for vectors? | 15:22 |
| programmerjake | yeah afaict sv.lwzu *1, ... is illegal | 15:27 |
| programmerjake | sv.lwzu 1, ... is legal, but sv.lwzu 64, ... is not | 15:27 |
| programmerjake | extra2 vector gprs/fprs have step 2, extra2 scalar gprs/fprs just go up to r63 | 15:29 |
| ghostmansd | A question from noob: why accessing vector register 1 is illegal? | 15:31 |
| ghostmansd | Even `sv.lwzu *126,16(63)` is legal. | 15:32 |
| ghostmansd | Unsurprisingly from what you tell, but surprisingly generally. Or I simply misunderstand the way vector registers are intended to work. | 15:33 |
| ghostmansd | Why odd registers are banned? | 15:34 |
| programmerjake | basically 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 msb | 15:35 |
| ghostmansd | Ah well pysvp64asm even doesn't give a shit about this: `sv.lwzu *666,16(63)` | 15:35 |
| ghostmansd | Yes, exactly, that's the question, actually: why not LSB? | 15:36 |
| ghostmansd | Thanks for putting it clearly. :-) | 15:36 |
| programmerjake | because 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 reg | 15:37 |
| programmerjake | vectors can get away with every other reg because we can assume they will usually use at 128-bits worth of registers | 15:38 |
| programmerjake | and we usually need lots of space just for vectors, not scalars | 15:38 |
| ghostmansd | But we won't be able to use 128-bits worth of registers on EXTRA2 | 15:38 |
| ghostmansd | I mean, we end up with 64 values anyway... | 15:39 |
| programmerjake | sv.lwzu *4, ... can load r4, r5, r6, r7, ... | 15:39 |
| programmerjake | so not being able to start at r5 is less of an issue | 15:40 |
| programmerjake | there's remap offset if we really need to | 15:40 |
| ghostmansd | OK I begin to understand | 15:40 |
| ghostmansd | But still perhaps I need somewhat good intro on vectors in general | 15:41 |
| ghostmansd | (perhaps not libresoc-specific, but rather in general) | 15:41 |
| programmerjake | lkcl, can i let you do that, i need to sleep | 15:41 |
| ghostmansd | ah right, totally forgot about the time diff | 15:41 |
| ghostmansd | sorry :-) | 15:41 |
| programmerjake | np | 15:41 |
| ghostmansd | sure, gn! thanks for tips! | 15:41 |
| programmerjake | it's nearly 8am here, i stayed up waay too late...ttyl | 15:43 |
| lkcl | ghostmansd, if you study any other vector ISA you'll find it doesn't help because they have a totally different paradigm | 16:09 |
| lkcl | other vector ISAs such as Cray have *actual* vector register files | 16:10 |
| lkcl | vr0: [element 0, element 1, element 2,..... element 1000] | 16:10 |
| lkcl | vr1: [element 0, element 1, element 2,..... element 1000] | 16:10 |
| lkcl | ... | 16:10 |
| lkcl | vr63 | 16:10 |
| ghostmansd | OK | 16:11 |
| ghostmansd | what does this do? field(spec, SPECb.MSB, SPECb.LSB, SPEC_SIZE) | 16:12 |
| lkcl | this how it works in Simple-V: https://libre-soc.org/openpower/svp64-primer/img/svp64_regs.svg | 16:12 |
| ghostmansd | I have an issue with MSB in vector/scalar | 16:12 |
| ghostmansd | And cannot get the order | 16:12 |
| lkcl | that's the equivalent of FieldSelectableInt | 16:12 |
| ghostmansd | what specific operation? | 16:13 |
| lkcl | it's a complete overkill way of returning spec[SPECb.LSB] concatenated with spec[SPECb.MSB] | 16:13 |
| ghostmansd | Aha, so it's concat | 16:13 |
| lkcl | yes but in inverted-bit-order | 16:14 |
| ghostmansd | why not Cat? | 16:14 |
| lkcl | because we wanted to keep the information about the MSB0 numbering in there | 16:14 |
| ghostmansd | OK. Say I have some extra2, and I have this: vector = extra2[0]; value_bit = extra2[1]. | 16:16 |
| lkcl | yep | 16:16 |
| ghostmansd | Depending on what vector equals to, what should I do with value_bit? | 16:16 |
| ghostmansd | if vector, I should shift up, so it ends up in MSB of 2-bit value? | 16:17 |
| ghostmansd | if not, I place it in LSB? | 16:17 |
| lkcl | again: that pseudocode | 16:17 |
| lkcl | no. other way round | 16:17 |
| ghostmansd | # Vector: shifted up, extra in LSBs (RA << 2) | spec[1:2] | 16:17 |
| lkcl | yes. | 16:17 |
| lkcl | remember MSB0-ordering bollocks | 16:17 |
| ghostmansd | Fuck it's so fucking annoying | 16:18 |
| ghostmansd | Wasting two hours for just putting this damn bit into the correct index and concatenating it. | 16:18 |
| lkcl | i know... | 16:18 |
| ghostmansd | OK, again | 16:18 |
| ghostmansd | let's just do it for these two bits | 16:18 |
| ghostmansd | I have bool(vector) and some damn bit | 16:19 |
| ghostmansd | What should I do? | 16:19 |
| ghostmansd | Simply give me the instruction, too tired to even think about this in MSB0 terms. | 16:19 |
| lkcl | on phone | 16:19 |
| ghostmansd | OK | 16:19 |
| lkcl | relax :) | 16:19 |
| ghostmansd | (consider just only this vector and this bit) | 16:20 |
| ghostmansd | I will adopt the suffix operand with it later | 16:20 |
| ghostmansd | Just "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 possible | 16:26 |
| ghostmansd | Or well, no. Let's use plain integers. | 16:34 |
| ghostmansd | Just assume I have bool(extra2[extra_idx][0]) and int(extra2[extra_idx][1]) | 16:34 |
| lkcl | ok am back | 16:35 |
| lkcl | let's set isvec=bool(extra2[extra_idx][0]) | 16:35 |
| lkcl | it's then: | 16:35 |
| lkcl | if isvec: | 16:35 |
| lkcl | return RA<<2 | int(extra2[extra_idx][1]) << 1 | 16:36 |
| lkcl | else: | 16:36 |
| lkcl | return RA<<2 | int(extra2[extra_idx][1]) <<5 | 16:36 |
| lkcl | whoops | 16:36 |
| lkcl | return RA | int(extra2[extra_idx][1]) << 5 | 16:36 |
| ghostmansd | How comes RA not in the end? | 16:39 |
| ghostmansd | RA goes first for vectors, for scalars shouldn't it be in the end | 16:40 |
| ghostmansd | Aaaah | 16:40 |
| ghostmansd | OK got it | 16:40 |
| ghostmansd | Fuck that's not concatenation it's logical OR | 16:40 |
| lkcl | *RA* gets shifted for vectors and... yes. | 16:40 |
| ghostmansd | So stressed. I'll make this stuff work and then take a break. | 16:40 |
| ghostmansd | OK so here's the problem I had: I shifted extra2[extra_idx][1] by 1 unconditionally. | 16:42 |
| lkcl | i see that - extra = (int(extra[1]) << 1) | 16:42 |
| lkcl | i think this is a reason why i did a conversion to an intermediate variable, "spec" | 16:43 |
| lkcl | but i see you are doing the same thing, just calling it still "extra" | 16:43 |
| ghostmansd | Yes but I do it regardless of vector mode | 16:43 |
| ghostmansd | This is the problem | 16:44 |
| ghostmansd | I _always_ shifted by 1 | 16:44 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 16:47 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 16:48 | |
| lkcl | yep i can confirm i just put sv.lwzu 62,16(47) into pysvp64asm and got .long 0x05401500; | 16:48 |
| lkcl | which matches with pysvp64dis | 16:49 |
| lkcl | 00 15 40 05 sv.lwzu r62,16,r47 | 16:49 |
| lkcl | that's after taking out the shift-by-one | 16:50 |
| lkcl | now, i must apologise, you'll have to experiment with EXTRA3. | 16:51 |
| lkcl | the existing code *MIGHT* be correct | 16: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 |
| lkcl | but it MIGHT be | 16:51 |
| ghostmansd | OK seems the task is done | 16:51 |
| lkcl | errmmm... thinking.... | 16:52 |
| ghostmansd | I'll post it soon | 16:52 |
| lkcl | extra = int(extra[1]) << 1 | int(extra[2]) | 16:52 |
| lkcl | ok cool | 16:52 |
| ghostmansd | I mean some examples | 16:52 |
| lkcl | hoorah | 16:52 |
| lkcl | i will try some as well | 16:53 |
| lkcl | i'll work it out | 16:53 |
| lkcl | you clearly need a break :) | 16:53 |
| lkcl | ah i spotted this | 16:53 |
| lkcl | RA | 16:53 |
| lkcl | 0101111 | 16:53 |
| lkcl | 23, {0}, 43, 44, 45, 46, 47 | 16:53 |
| lkcl | that should be {0}, 23, 43, .... | 16:53 |
| lkcl | i can sort that out | 16:53 |
| ghostmansd | Nah | 16:54 |
| ghostmansd | Just noticed that | 16:54 |
| lkcl | extra_span = (extra_span + ("{0}",)) | 16:54 |
| lkcl | should be | 16:54 |
| lkcl | extra_span = (("{0}",) + extra_span) | 16:54 |
| lkcl | real easy. want me to do it? | 16:54 |
| *** tplaten <tplaten!~isengaara@d536ce0a.access.ecotel.net> has joined #libre-soc | 16:55 | |
| ghostmansd | yeah | 16:55 |
| ghostmansd | this is what I just did | 16:55 |
| ghostmansd | lol | 16:55 |
| lkcl | doh :) | 16:55 |
| ghostmansd | pushed | 16:55 |
| ghostmansd | now to immediates | 16:55 |
| ghostmansd | I 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 better | 16:55 |
| lkcl | yes it should be sv.lwzu r62,16(r47) btw | 16:56 |
| ghostmansd | we already applied this cheat for immortability in spec | 16:56 |
| ghostmansd | so I guess it won't hurt to cheat more | 16:56 |
| * lkcl snorts | 16:56 | |
| ghostmansd | (yeah this should have been a function) | 16:56 |
| lkcl | HA! cool! extra2 vector works! | 17:04 |
| lkcl | ok let's try an EXTRA3. an sv.add. | 17:08 |
| lkcl | HA! even cooler - EXTRA3 vector works too | 17:12 |
| lkcl | so that _is_ the right way round (in the spec page) | 17:14 |
| ghostmansd | yeah, I wouldn't still call it clear there :-) | 17:15 |
| * lkcl snorts | 17:15 | |
| ghostmansd | but OK, perhaps only MSB0 confuses me | 17:15 |
| lkcl | you and both of me both | 17:15 |
| ghostmansd | lol | 17:16 |
| lkcl | 18 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 |
| ghostmansd | heh | 17:17 |
| ghostmansd | I fixed immediates | 17:17 |
| ghostmansd | really success story today | 17:17 |
| ghostmansd | 00 25 40 05 lwzu *r0,16(r63) | 17:18 |
| ghostmansd | 10 00 1f 84 | 17:18 |
| ghostmansd | I moved it to common class, because operands do alredy check insn type (SVP64 or not) | 17:18 |
| lkcl | echo -n -e '\x00\x3a\x40\x05\x10\x00\xec\x85' | pysvp64dis -v | 17:19 |
| lkcl | 00 3a 40 05 lwzu *r62,16(*r48) | 17:19 |
| lkcl | 10 00 ec 85 | 17:19 |
| lkcl | aawwesome | 17:19 |
| ghostmansd | Yeah that's a cheat | 17:19 |
| ghostmansd | joyful grunting | 17:19 |
| lkcl | spec | 17:19 |
| lkcl | sv.lwzu r10,14848(r0) | 17:19 |
| lkcl | oo-err | 17:19 |
| ghostmansd | Wow :-) | 17:19 |
| ghostmansd | Missed that | 17:19 |
| lkcl | 14848? moo? :) | 17:19 |
| ghostmansd | no idea | 17:19 |
| ghostmansd | also for r10 | 17:20 |
| ghostmansd | aaaah | 17:20 |
| ghostmansd | fuck, should've used name there, not value | 17:20 |
| ghostmansd | copy & paste | 17:21 |
| lkcl | doh :) | 17:21 |
| lkcl | spec | 17:21 |
| lkcl | sv.add RT,RA,RB (OE=0 Rc=0) | 17:21 |
| lkcl | changed to random-numbers-etc. | 17:21 |
| ghostmansd | aha | 17:21 |
| lkcl | and missing "sv." in front... | 17:21 |
| ghostmansd | yeah it gets the value lol | 17:21 |
| lkcl | 00 3a 40 05 >>>sv.<<<lwzu *r62,16(*r48) | 17:21 |
| ghostmansd | oo good catch | 17:22 |
| lkcl | sooo | 17:22 |
| ghostmansd | 1 sec | 17:22 |
| lkcl | maaaany | 17:22 |
| lkcl | deeetaiiiils.... | 17:22 |
| ghostmansd | I haven't even started printing all fields yet! | 17:22 |
| lkcl | well if this turns into a bottomless pit we truncate it ok? | 17:23 |
| lkcl | task equals defined as success | 17:23 |
| ghostmansd | OK another take | 17:27 |
| ghostmansd | it's already the bottomless pit lol | 17:27 |
| ghostmansd | any time I return to this task I always find there's something left | 17:28 |
| ghostmansd | anyway, if we really won extras, this is already sufficient reason to switch binutils to this code | 17:28 |
| ghostmansd | in binutils, this was AWFUL | 17:28 |
| ghostmansd | and also I recently found that EXTRA2 doesn't work there at all | 17:29 |
| ghostmansd | `sv.lwzu 63,16(63)` shits in my eyes with "Error: cannot remap EXTRA" | 17:29 |
| ghostmansd | so yeah new fields are the way to go | 17:30 |
| ghostmansd | ideally I'd drop these if/else crap in DynamicOperandReg, but even this is better compared to what we have now | 17:30 |
| ghostmansd | I should've asked you about this damn bit in EXTRA2 before, really :-) | 17:31 |
| ghostmansd | having it the way you wrote explains it much better than the pseudocode | 17:31 |
| ghostmansd | I literally spend 2+ hours there | 17:31 |
| ghostmansd | so, my summary: FUCK MSB0! | 17:32 |
| ghostmansd | CRs will be even worse I guess | 17:32 |
| ghostmansd | but perhaps bits of DynamicOperandReg can be re-used | 17:32 |
| ghostmansd | Do we have other tricky parts except for CRs? | 17:33 |
| ghostmansd | Is everything else straightforward? I'm not so sure abot specifiers, perhaps they will need more tuning, too. | 17:34 |
| ghostmansd | Likely will be a reverse-engineering of pysvp64asm | 17:34 |
| ghostmansd[m] | lkcl, FYI: https://libre-soc.org/irclog/%23libre-soc.2022-09-07.log.html#t2022-09-07T15:35:37 | 17:59 |
| 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 |
| lkcl | CRs are not that bad (he said, ha ha) | 18:10 |
| lkcl | but you have to remember one other thing | 18:10 |
| lkcl | firstly, the easy part | 18:10 |
| lkcl | those shift amounts "RA<<2 | extra" and "extra<<5 | RA" have to be adapted to 3-bit | 18:11 |
| lkcl | so | 18:11 |
| lkcl | errr | 18:11 |
| *** octavius <octavius!~octavius@197.147.93.209.dyn.plus.net> has quit IRC | 18:11 | |
| lkcl | "CRf << 4 | extra<<2" for EXTRA3 vector and "extra2<<5 | CRf<<2" for scalar, something like that | 18:12 |
| lkcl | (basically look at the table in the spec) | 18:12 |
| lkcl | but that's 3-bit *fields* | 18:12 |
| lkcl | there are also *FIVE* bit CR-accessers | 18:13 |
| lkcl | (because the CR *Register* is a 32-bit quantity, comprising 8 fields of 2-bits each) | 18:13 |
| lkcl | so for the *FIVE* bit accessors you must first strip out the top THREE bits (containing the 3-bit CR *FIELD* number) | 18:13 |
| lkcl | then go through the 3-bit procedure | 18:13 |
| lkcl | then SHIFT THAT UP BY TWO and drop in the 2-bits of e.g. BA/BO | 18:14 |
| tplaten | My 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 |
| lkcl | whilst all the time remembering that the access is all in MSB0 numbering. | 18:15 |
| lkcl | tplaten, brilliant! | 18:15 |
| lkcl | do put it on the conferences page https://libre-soc.org/conferences | 18:15 |
| lkcl | but, now that you have GPR/FPR working, you can compare against the GPR/FPR tables | 18:16 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/#index13h1 | 18:16 |
| lkcl | at least now go "bloody hell that was so much simpler now it's implemented, i actually recognise those tables now" | 18:17 |
| lkcl | and from there comparatively-deduce the above logic, for CRs. | 18:17 |
| tplaten | I'll do this weekend | 18:19 |
| lkcl | star | 18:20 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18:20 | |
| tplaten | I will also participate at https://guix.gnu.org/en/blog/2022/celebrating-10-years-of-guix-in-paris/ | 18:20 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.220> has joined #libre-soc | 18:21 | |
| lkcl | nice! | 18:22 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.220> has quit IRC | 18:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.220> has joined #libre-soc | 18:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.220> has quit IRC | 18:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:32 | |
| ghostmansd[m] | Ok will check tomorrow | 18: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 time | 19:00 |
| sadoon[m] | Which ironically is a feature pbuild already has but sbuild doesn't seem to | 19: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 updates | 19:01 |
| sadoon[m] | then it's a matter of toying with gcc and clang to force them to build ppc64le without any vector extensions | 19: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 archive | 19:02 |
| sadoon[m] | I'm also building everything in RAM which is a major speedup, things are looking really good so far | 19:05 |
| lkcl | sadoon[m], you can kiinda install a transparent apt-proxy-cache and point at that instead of the direct thing | 19:16 |
| lkcl | do you have ccache also installed? | 19:16 |
| lkcl | might help speed things up too | 19:16 |
| lkcl | particularly given that 95% of debian packages are "reproducible build" now | 19:17 |
| sadoon[m] | ccache is worrying because we want clean builds | 19:17 |
| lkcl | there's no particular rush on this | 19:17 |
| lkcl | ccache _does_ give clean builds | 19:17 |
| lkcl | i've never seen it fail in 20 years of using it | 19:18 |
| sadoon[m] | i'll look into apt-proxy-cache | 19:18 |
| sadoon[m] | oh nice | 19:18 |
| sadoon[m] | definitely then | 19:18 |
| lkcl | it's extremely clever | 19:18 |
| sadoon[m] | both of them I guess | 19:18 |
| sadoon[m] | I'll need a beefier SSD to fit everything and that's it | 19:18 |
| lkcl | basically it understands the full syntax of gcc and clang | 19:18 |
| lkcl | then performs a "gcc -E" | 19:19 |
| lkcl | combines the output of that with the full command-line options | 19:19 |
| lkcl | performs a hash | 19:19 |
| lkcl | and 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 :D | 19:19 |
| sadoon[m] | lkcl: very cool, will integrate it then | 19:19 |
| lkcl | if the *entire* output from "gcc -E" and the command-line options are identical, you *know* that the rsults are going to be the same | 19:19 |
| lkcl | it 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 |
| lkcl | pffh *snort* | 19:20 |
| sadoon[m] | so this is not just a basic linux environment | 19:20 |
| lkcl | dang | 19:20 |
| sadoon[m] | hey I mean at least it helps my g4 and g5 machines right? | 19:21 |
| lkcl | :) | 19:21 |
| lkcl | yes | 19:21 |
| sadoon[m] | I can actually get on gitlab and stuff | 19:21 |
| sadoon[m] | iirc | 19:21 |
| lkcl | holy cow | 19:21 |
| sadoon[m] | strange, apt-mirror wants to download 69 gigabytes even though I see all the packages inside.. | 19:22 |
| lkcl | that's apt-mirror | 19:23 |
| lkcl | that's literally mirroring the entire distro | 19:23 |
| lkcl | all 40,000 packages if you're using testing | 19:23 |
| sadoon[m] | yes but it continues when it sees you already have files downloaded | 19:23 |
| sadoon[m] | I think I messed up the directory | 19:23 |
| lkcl | you probably want https://wiki.debian.org/AptCacherNg | 19:24 |
| sadoon[m] | No I do want apt-mirror actually because these files will be useful later for other things | 19:24 |
| sadoon[m] | And I also want to mirror many older releases of ubuntu and debian for.. reasons :P | 19:25 |
| sadoon[m] | two birds one stone | 19:25 |
| lkcl | ha, there you go | 19: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 now | 19:26 |
| sadoon[m] | By it I mean the local archive | 19:26 |
| lkcl | you can't "totally" mess up because of digital signatures. | 19:26 |
| lkcl | but | 19:26 |
| lkcl | bear in mind | 19:26 |
| lkcl | that depending on the time, if you are doing testing, security, updates or backports | 19:27 |
| lkcl | you *can* end up catching things right in the middle of an update | 19:27 |
| lkcl | and have half the packages downloaded but the other half are gone because they were replaced with newer versions | 19:27 |
| lkcl | if your ***ISP*** has a transparent cacheing proxy on the front with fucked-up timeouts, it gets even worse | 19:28 |
| sadoon[m] | that's normally the case but remember that I'm downloading a sid snapshot from March 2021 | 19:28 |
| sadoon[m] | And we're going to rebuild everything from scratch targeting bullseye anyways | 19:28 |
| lkcl | bullseye should not change, as long as you don't also try to include security updates, volatile, or bullseye-updates or backports | 19:29 |
| sadoon[m] | what I have as a mirror is sid when bullseye was frozen | 19:30 |
| sadoon[m] | Which is enough to build bullseye completely :D | 19: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 feeds | 19:31 |
| sadoon[m] | It was hell | 19:31 |
| sadoon[m] | But it was a theory and it worked | 19:31 |
| lkcl | joooy | 19:32 |
| sadoon[m] | apt is not liking my sshfs mounted mirror.. permission issues | 19:46 |
| sadoon[m] | the vm does not have direct access to the server so I have to find another solution | 19:47 |
| *** octavius <octavius!~octavius@197.147.93.209.dyn.plus.net> has joined #libre-soc | 19:48 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:15 | |
| *** tplaten <tplaten!~isengaara@d536ce0a.access.ecotel.net> has quit IRC | 20:46 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:54 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 21:01 | |
| programmerjake | in theory mounting a ext4 filesystem on a file in a sshfs mounted directory should work... | 21:17 |
| programmerjake | should fix permission issues | 21:17 |
| openpowerbot | [irc] <toshywoshy> ping meeting LibreSOC | 22:03 |
| octavius | programmerjake, markos, sadoon, meeting | 22:03 |
| programmerjake | lkcl: jitsi bugged out again, there's like 48 fptrans ops | 22:35 |
| programmerjake | lkcl: 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 isas | 22:59 |
| programmerjake | lower levels* | 23:00 |
| *** markos <markos!~Konstanti@178.59.251.230> has quit IRC | 23:01 | |
| programmerjake | stuff like fft and matrix can reasonably be left for the upper levels | 23:01 |
| *** octavius <octavius!~octavius@197.147.93.209.dyn.plus.net> has quit IRC | 23:08 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
