| lkcl | octavius, Simple-V is the name of the Vector System. P64 is "Prefix length of 64". Simple-V comma Prefixed to 64 bit. SV-P-64. | 00:25 |
|---|---|---|
| lkcl | ghostmansd, will reply tomorrow, i missed this. generally, doing unit tests with 5*5*7*2*2*2 options will take far too long | 00:28 |
| lkcl | but selecting say one loop of size 10 with a tuple of random values (RT, RA, SVi) so 20*2*2*2 you can probably get away with. | 00:28 |
| lkcl | and/or go through HI-LO bits | 00:29 |
| programmerjake | hmm, i'd expect 5*5*7*2*2*2=1400 tests to be reasonably fast to run...the issue is if we have to put 1400 expected results in a source file somewhere since that seems excessive | 00:35 |
| octavius | Thanks Luke! | 00:39 |
| ghostmansd | programmerjake is right; even 10K+ is OK time-wise, but does seem excessive for reviewing | 05:56 |
| ghostmansd | lkcl, we don't check all possible cases, only corner ones: https://pastebin.com/sQYfvnEx. I suspect even the former can be reduced somewhat. | 05:58 |
| ghostmansd | OK when in doubt it won't hurt to ask on a mailing list. | 06:12 |
| ghostmansd | https://sourceware.org/pipermail/binutils/2022-June/121275.html | 06:12 |
| ghostmansd | I've also just sent an e-mail to fsf-records at GNU organization so that they could update us on status of copyright assignment. It's been almost one month for copyright assignment, and Alan told me it generally takes about a week. I remember it took more time in 2012 for gnulib, but I think it was less than a month. | 06:21 |
| ghostmansd[m] | Fuck. I've just discovered that since July 16 any incoming USD/EUR transactions are under 3% fee, but no less than 200 EUR/USD respectively. | 09:30 |
| ghostmansd[m] | That's in addition to 13% the government already takes. | 09:30 |
| programmerjake | fun.... | 09:30 |
| ghostmansd[m] | That'll be bank's fee. | 09:30 |
| ghostmansd[m] | Perhaps I'll switch bank. | 09:30 |
| ghostmansd[m] | You'd be surprised but they tell it's not their fault. Since Western systems proved to be unreliable, this is kinda insurance. | 09:32 |
| programmerjake | well, imho 200USD minimum fee seems kinda high...the 3% fee seems ok-ish but not amazing | 09:37 |
| programmerjake | hopefully it'll work out for you | 09:37 |
| programmerjake | afaict my bank charges a flat $16 fee for EUR/USD | 09:38 |
| programmerjake | makes me think it might be cheaper to convert EUR -> BTC -> RUB | 09:40 |
| lkcl | oof, am a bit behind on irc messages | 09:59 |
| lkcl | ghostmansd[m], so are you talking about adding unit tests to *binutils* or to openpower-isa? | 09:59 |
| ghostmansd[m] | binutils, cf. [08:12] ghostmansd: https://sourceware.org/pipermail/binutils/2022-June/121275.html | 10:00 |
| lkcl | because i had the thought that perhaps leveraging openpower-isa to simply auto-output some unit tests, from listings, would save a huge amount of time | 10:01 |
| ghostmansd[m] | Fuck. Users asked bank what happens if someone sends 150 USD. | 10:01 |
| ghostmansd[m] | The bank replied they'll taka all. | 10:02 |
| ghostmansd[m] | That's fucking insane. | 10:02 |
| lkcl | niiice | 10:03 |
| ghostmansd[m] | I'll write to Michiel and ask them to change the account. | 10:03 |
| lkcl | what, of the already-sent RFP? | 10:03 |
| ghostmansd[m] | Perhaps they haven't sent the payment yet? | 10:03 |
| ghostmansd[m] | Or is it already too late? | 10:03 |
| lkcl | if so do that straight away, send a *replacement* RFP rather than ask "please change the account" | 10:03 |
| programmerjake | let me guess, you owe them $50 for the privilege of receiving less than their minimum fee? | 10:04 |
| lkcl | the way it works is they have to "draw down" money from the EU Grant | 10:04 |
| lkcl | so there is *maybe* a delay window of opportunity (2-3 weeks) | 10:04 |
| lkcl | but send the replacement RFP as quickly as you can with the least fuss and stress | 10:04 |
| lkcl | don't go "these moronic bank fuckers", just be very straightforward, "bank fees have increased so much that i need to use a different bank account, please replace this RFP" | 10:05 |
| lkcl | "sorry for inconvenience", etc etc | 10:06 |
| lkcl | programmerjake, i'd really like there to have been room / time to do the 16-bit variant with a 16-bit prefix, we may have to revisit VLE-Encoding at some point | 10:07 |
| lkcl | but when there's less time-pressure and when OPF Members in the ISA WG have gotten over the hump of a 120+ page External RFC submission :) | 10:08 |
| programmerjake | if you don't have a different bank account yet, you could ask them to wait until you have one and can submit a fixed RFP | 10:12 |
| lkcl | cesar, those RFPs all look great, once submitted do update the "submitted = " date in the TOML fields of all three | 10:12 |
| lkcl | ghostmansd, zeek! okaaay so you *are* actually thinking of auto-generating the tests. | 11:17 |
| lkcl | that being the case, you might want to consider actually doing them as openpower-isa unit tests and having it actually *output* the assembler into a file | 11:18 |
| lkcl | this was something that was planned / discussed with kylel mmm... 6 months ago? | 11:18 |
| * lkcl waves to kylel | 11:18 | |
| ghostmansd | automating it on binutils side is rather difficult; they should not depend on openpower-isa in any way, this is not acceptable | 11:19 |
| ghostmansd | but WE could depend on binutils | 11:19 |
| ghostmansd | because, hey, we already DO | 11:19 |
| lkcl | yeah it'd fall into the same category as binutils-svanalysis | 11:19 |
| ghostmansd | well, we either have some generator and commit its output to binutils... | 11:20 |
| lkcl | true... but we currently depend on the upstream stable binutils-ppc64 | 11:20 |
| ghostmansd | ...or we have some stuff in binutils and feed them to openpower-isa | 11:20 |
| lkcl | yes, that was the thought. | 11:20 |
| ghostmansd | well, we already made the step away from upstream stable, right? | 11:20 |
| lkcl | the logical extension to that idea is to actually auto-generate the Makefile | 11:21 |
| ghostmansd | with Veera[m] script | 11:21 |
| lkcl | true, but i would like to see it be an *option* to use that | 11:21 |
| ghostmansd | yeah I totally agree | 11:21 |
| lkcl | rather than make it a hard dependency and retire svp64.py | 11:21 |
| lkcl | because of binutils's size | 11:21 |
| ghostmansd | I'm not sure how to approach it better. Ideally we should deal with operands on openpower-isa side. | 11:21 |
| ghostmansd | The whole stuff. Both operands generation and tests. | 11:22 |
| lkcl | the openpower-isa unit tests aren't actually unit tests | 11:22 |
| lkcl | or | 11:22 |
| ghostmansd | This closely matches the task about instruction forms synchronization. | 11:22 |
| lkcl | the tests are separated out and you have to *mix in* what you actually want to do with them | 11:23 |
| lkcl | so it is perfectly possible to utilise those classes for the purposes of auto-generating "something" | 11:23 |
| ghostmansd | I think the only choice is to periodically generate stuff on openpower-isa side and commit it to binutils. | 11:23 |
| ghostmansd | Because we already have most of the machinery. | 11:23 |
| lkcl | i agree: i mean it's a total nightmare to maintain two separate sets of tests | 11:24 |
| ghostmansd | This includes some C sources, some C headers, and, logically extending, tests. | 11:24 |
| ghostmansd | I mean binutils above. | 11:24 |
| ghostmansd | These are the files we'll generate, and commit to binutils. | 11:24 |
| lkcl | btw if done carefully there *may* be a separate budget in a separate NLnet grant for this one | 11:26 |
| ghostmansd | Operands parsing is essential. It's difficult on binutils side. | 11:26 |
| lkcl | the MoU has to be agreed, though. it's covered by the cavatools / simulator grant | 11:26 |
| ghostmansd | MoU is not an issue | 11:43 |
| lkcl | toshywoshy, thx, i saw https://bugs.libre-soc.org/show_bug.cgi?id=860 | 15:52 |
| lkcl | i've not linked it to the milestone yet (not set the drop-down to "NGI POINTER") because doing so will activate the budget reconciliation | 15:53 |
| lkcl | and i'd have to do a lot of work adding up budgets at that point :) | 15:54 |
| ghostmansd | OK I've submitted patches for the very first 32-bit insns for SVP64 | 20:10 |
| ghostmansd | https://sourceware.org/pipermail/binutils/2022-June/121284.html | 20:10 |
| programmerjake | interesting reading about why C is and will continue to be a mess: https://thephd.dev/your-c-compiler-and-standard-library-will-not-help-you | 20:24 |
| ghostmansd[m] | I forgot to mention that these patches are in standalone branch, svp64-ng, and this branch will be used as basis for submissions to review | 20:41 |
| ghostmansd[m] | So cleanup will be here, so will macros | 20:41 |
| programmerjake | luke, i'll be watching your yt video later, note that you should be comparing against SSE2 and AVX2 and AVX512 --- basically no one uses MMX anymore because it has poorly thought out sharing of mmx registers with the x87 fpu register stack | 20:47 |
| programmerjake | llvm won't even generate mmx instructions unless you specifically use mmx intrinsics, vector types do not turn into mmx instructions, they're either scalarized or turn into sse/avx/avx512 instructions | 20:49 |
| programmerjake | https://www.tomshardware.com/news/neox-series-risc-v-3d-gpus-will-be-demonstrated-next-week | 21:06 |
| lkcl | ghostmansd[m], hooray! | 21:48 |
| lkcl | programmerjake, i gave the example of mmx precisely and only because it does in fact overload the register file. | 21:49 |
| lkcl | i forgot, during the video, that RISC-V RVV "embedded" mode can overlay the FP regfile as well | 21:49 |
| programmerjake | another one that overloads the register file is old mips f32x2 simd (icr the actual name, but it treats a f64 register as 2x f32) | 21:57 |
| programmerjake | and vsx too | 21:58 |
| lkcl | i | 21:59 |
| lkcl | i wanted to use an example that i knew went all the way down to 8x8 | 21:59 |
| programmerjake | also, on x86_64, the sse registers *are* the fp registers that everyone uses | 21:59 |
| lkcl | and was on top of 64-bit | 21:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!