Thursday, 2023-06-22

*** ibot` <ibot`!> has quit IRC02:50
*** ibot <ibot!~supybot@2a00:1098:82:f::1> has joined #libre-soc02:51
lkclghostmansd, i had to get things working. you hadn't run the full unit tests and i had to do the best i could in desperation as an emergency measure.09:45
lkcl> list, opcodes, pcode and extras work!09:46
lkclahh fantastic09:47
lkclconfirmed working, awesome09:50
lkclah i get blank from the pcode command09:50
lkcl$ pysvp64db opcodes add09:50
ghostmansdthat's not committed yet09:53
ghostmansdI'll commit all-in-one09:53
ghostmansdSo you effectively check the old implementation :-)09:54
programmerjakelkcl: if you have some free time, can you look at
programmerjakebasically fmv* fcvt* need to be renamed and i proposed a new naming scheme along with an optionally using existing fpr-gpr move instructions (adjusted for SFFS) instead of us proposing new ones09:58
programmerjakerenaming is the last step before getting people to review it and submitting it09:59
programmerjakeunless you want to wait for potential po9 encodings of fcvt/fmv?10:00
lkclahh if it's following existing established conventions i'm fine with that (saw #43)10:05
lkclrats, that's another thing on the list for the ISA WG, we have zero guidance on instruction naming conventions10:05
programmerjakeok, what about the using existing double-precision fpr-gpr move instructions (made part of SFFS) instead of introducing our own? we'd still be proposing the new single-precision variants10:09
lkclthere's existing fpr-gpr move instructions??10:14
lkclah no those are "pseudo-ops"10:15
lkclwe can't use them10:15
lkclExtended mnemonic: Equivalent to:10:16
lkclmtfprd      FRT,RA mtvsrd         FRT,RA10:16
lkclp121 section 3.3.7 book I10:16
lkclhas to be separate instruction names.10:16
lkclimagine the chaos of proposing an actual instruction to replace a pseudo-alias for the same thing10:17
lkclit would become non-orthogonal10:17
lkclhow would Vectorisation of those instructions work?  it couldn't10:18
programmerjakei'm proposing we add the part of those vsx instructions that only touches fprs/gprs to SFFS, calling them by their alias is just a handy shortcut for saying all of that10:20
lkclabsolutely not10:21
programmerjakevectorization could work just fine since those are *scalar* instructions10:21
lkclaside from anything it creates a hard-link at the Decode phase, onto VSX instruction decoding10:21
lkclVSX needs to be treated entirely separate and kept entirely separate so that at some point in the future SVP64:VSX can be dropped on top of it10:22
lkcland the absolutely absolutely crucial thing to bear in mind when doing that is that it may be a COMPLETELY different encoding scheme from SVP64:SFS/SFFS10:22
programmerjakethey can be called mfvsrd/mtvsrd in the actual proposal10:22
lkcland no10:23
lkclthat's hard no: please listen10:23
programmerjakeah, ok. that will need to be mentioned as a motivating factor10:23
lkclplease make the effort to understand why i am saying "no" here10:23
lkclah there's some latency on IRC10:24
programmerjaketakes a while for me to type on my phone10:24
lkclit's taken me some considerable time to work out why i am uncomfortable with suggestions that Paul made which were "why don't you use VSX instructions that do the same job?"10:24
lkclaw doh :)10:24
lkcland it's because of the non-Orthogonality that results when SVP64:VSX is introduced (potentially with entirely new SVP64 encoding, or at least better-suited to VSX)10:25
programmerjakespeaking of that, paul proposed an encoding for fp load immediate that imho should work well10:25
lkclahhh nice. i'm barely keeping up at the moment10:26
programmerjakewhen you want 32-bit immediates10:26
programmerjakei responded to him10:26
lkclok great. i'll catch it later, need water10:26
programmerjakei'll link to this conversation in the int/fp move one10:27
*** ghostmansd <ghostmansd!> has quit IRC10:27
lkclgood idea.10:28
lkcli need to raise an issue on the ISA WG issue tracker about instruction-naming guidance10:29
*** ghostmansd <ghostmansd!> has joined #libre-soc10:30
*** ghostmansd[pc] <ghostmansd[pc]!> has joined #libre-soc10:40
*** ghostmansd <ghostmansd!> has quit IRC10:43
*** ghostmansd[pc] <ghostmansd[pc]!> has quit IRC11:04
*** ghostmansd[pc] <ghostmansd[pc]!> has joined #libre-soc11:05
markos_lkcl, check c12 on #1092, that's similar to what I had written, a 32-bit fp load immediate makes quite a difference12:06
markos_if we can do it, we should, if there is a need for bf16 load immediate, just use the fp32 one with a 16-bit value12:09
markos_after all bf16 is fp32 shifted12:09
markos_sadly that's not the same as fp1612:10
markos_hm, no, that's not going to work12:14
markos_it needs a separate instruction12:14
markos_a 16-bit value could be a bf16 with non-zero exponent, or a fp32 with zero exponent and clamped fraction parts12:15
markos_in any case, I'd really like a 32-bit fp load immediate12:16
markos_but a bf16 one is also useful ftm12:17
ghostmansd[pc]5 failures vs 5 same failures on master12:20
*** ghostmansd[pc] <ghostmansd[pc]!> has quit IRC12:26
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:04
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:05
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:38
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc13:58
*** ghostmansd <ghostmansd!> has joined #libre-soc14:33
*** ghostmansd <ghostmansd!> has quit IRC14:53
*** ghostmansd <ghostmansd!> has joined #libre-soc16:08
ghostmansdsomething's lost from commit16:27
ghostmansdhang on, I'm fixing it16:27
ghostmansdYeah it seems 1 commit is missed. Nothing was broken except for pysvp64db, which isn't run in tests. I've pushed a fix anyway.16:32
ghostmansdGuys, let me know if you have any objections on adding more pysvp64db commands:
ghostmansdI know that the core of this task (provide visitor API) is completed. But I think this script is going to be useful, plus I'd like to check visitors for other classes. Let me know if you have objections.16:41
markos_would be nice to know which ones are already there, I'm not going through 240 comments to find out which commands exist :)16:41
markos_maybe a short readme?16:41
ghostmansdpysvp64db --help to the rescue!16:43
ghostmansdargparse generates help for us automatically16:44
ghostmansdI knew you'd be the first to ask :-)16:44
markos_am I so predictable? :D16:44
ghostmansdOh, by the way, it'd be great if you share your needs too. I think you wrote a lot of asm code, so I suspect you already have some victims in mind. :-)16:45
ghostmansdNope, just that I know you're our main assembly users, or at least one of major ones. :-)16:45
markos_I need to finish something first, but sure I'd be glad to help16:45
ghostmansdAnd I think you'll find this tool useful for exploring which instructions we have and what arguments/opcodes/etc. they have.16:46
markos_you mean to say "you are one of the crazy ones"16:46
ghostmansdNot at all :-D16:46
ghostmansdOr, well, at least in a good sense!16:46
ghostmansd$ pysvp64db pcode addi16:46
ghostmansdRT <- (RA|0) + EXTS(SI)16:46
ghostmansdThat's just one of examples of what might come handy16:47
markos_this is nice16:47
markos_I have already thought of a use case for this16:47
markos_I'll think about it a bit more16:48
markos_but we can get autogenerated visual representation of the instruction that way, eg. auto export a graphviz/dia code for a graph visualization16:49
markos_long term16:50
markos_do we categorize the instructions in any way?16:54
markos_eg. addition, multiplication, shift, etc16:54
markos_if we have something like that, we could do a tree-like representation16:54
*** ghostmansd <ghostmansd!> has quit IRC17:02
ghostmansd[m]Hm. I think the best option we have now is grouping by module (e.g. ALU).17:04
markos_is it easy to add some kind of tagging/category?17:06
ghostmansd[m]I don't think we have anything which marks instructions as "hey bruh, I add!". Our closest equivalent is "hey bruh, I do some arithmetic operation, go read my name or even pcode to tell which one!".17:06
ghostmansd[m]We could mark each insn in CSVs, but this would conflict with Microwatt. On the other hand, I think we already have some non-standard fields (e.g. "unofficial" field).17:07
ghostmansd[m]This would be a big work, but I see some use cases for it too.17:07
markos_yeah, there is no rush, but might be nice to have eventually17:08
ghostmansd[m]Adding support for another field is trivial (just a new field in dataclasses). The marking would be tedious, though, because we need to establish these categories... And then go over... I don't know, 600+ instructions?17:08
ghostmansd[m]But certainly doable.17:09
*** ghostmansd <ghostmansd!> has joined #libre-soc17:16
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC17:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:34
markos_ghostmansd, I've been doing that for Intel, Arm, Power for over 17k intrinsics so, tedious, yes, but also doable :)17:47
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:51
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:51
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:00
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:00
*** tplaten <tplaten!~tplaten@> has joined #libre-soc18:08
*** tplaten <tplaten!~tplaten@> has quit IRC18:30
*** ghostmansd <ghostmansd!> has quit IRC19:36
*** ghostmansd <ghostmansd!> has joined #libre-soc19:36
*** ghostmansd <ghostmansd!> has quit IRC19:49
*** ghostmansd <ghostmansd!> has joined #libre-soc19:49
ghostmansdI found that mdis should predate openpower-isa setup. Only revealed recently, when insndb/ had new walker class introduced. Symptoms: we run in openpower-isa and it fails due to yet unresolved mdis dependency.22:16
ghostmansdI couldn't find it before, because I already had mdis module installed in developer mode.22:16
ghostmansdThe fix for hdl-dev-repos is committed, waiting for CI.22:17
ghostmansdJacob, does CI track changes in dev-env-setup?22:18
programmerjakeno, though i'm thinking of building a repo with autoupdated submodules for all our git repos so we can run ci on everything22:19
programmerjakemdis should be added to .gitlab-ci.yml in openpower-isa and soc, copy the code section for nmutil22:20
*** ghostmansd <ghostmansd!> has quit IRC22:24
*** ghostmansd <ghostmansd!> has joined #libre-soc22:24
ghostmansd[m]Thanks for tip, Jacob! I added the mdis commands. This is taken from hdl-dev-repos script, right? Shouldn't we perhaps just call it?22:28
programmerjakeit's different than hdl-dev-repos, eventually we should just call it, but getting that working will be a bit of work, so i'm putting that off for later22:30
programmerjakedo remember to add mdis to soc.git too22:31
programmerjakeif you get different ci results than the last soc.git ci, don't worry too much, that was months ago and if something breaks it likely wasn't you adding mdis22:32
ghostmansdHm. I've never used soc directly I think. Does it depend on openpower-isa?22:44
ghostmansdAh wait, even if it does, it won't help. OK, I'll update it too.22:44
programmerjakesoc depends on openpower-isa22:45
programmerjakesince openpower-isa generates the decoder and has the test infrastructure and test cases and other stuff22:46
programmerjakehence why most openpower-isa tests are split between a class in a separate file and a top-level runner file22:47
ghostmansdFATAL: W any soc ghostmansd DENIED by fallthru22:48
programmerjakeso soc can just import that class and run all tests on a simulation of libre-soc's hdl core22:48
programmerjakelkcl: ^ please grant ghostmansd access to soc.git22:48
ghostmansdSorry Jacob, out of mana22:49
programmerjakeok, sleep well22:49
ghostmansdthank you for your help again!22:49
*** ghostmansd <ghostmansd!> has quit IRC22:50
sadoon[m]Has anyone seen the RHEL situation?23:26
sadoon[m]Good thing we base all our stuff on Debian huh?23:27
sadoon[m]Yet I still don't have a strong opinion on either side tbf, too many conflicting arguments23:27
sadoon[m]The more I dig into this, the less I understand it23:36
rscIBM, who owns Red Hat, obviously needs to grow their revenue. Firing employees didn't make enough money.23:53
rscActually, it even might be a decision by Red Hat on its own, who knows.23:53
rscNote, I am not a Red Hat employee, just a long-time free time/hobby contributor to Fedora and especially EPEL.23:54

Generated by 2.17.1 by Marius Gedminas - find it at!