| *** ibot` <ibot`!~supybot@libre-soc.org> has quit IRC | 02:50 | |
| *** ibot <ibot!~supybot@2a00:1098:82:f::1> has joined #libre-soc | 02:51 | |
| lkcl | ghostmansd, 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 |
| lkcl | ahh fantastic | 09:47 |
| lkcl | confirmed working, awesome | 09:50 |
| lkcl | ah i get blank from the pcode command | 09:50 |
| lkcl | $ pysvp64db opcodes add | 09:50 |
| lkcl | 011111---------------01000010100 | 09:50 |
| ghostmansd | that's not committed yet | 09:53 |
| ghostmansd | I'll commit all-in-one | 09:53 |
| ghostmansd | So you effectively check the old implementation :-) | 09:54 |
| programmerjake | lkcl: if you have some free time, can you look at https://bugs.libre-soc.org/show_bug.cgi?id=1015#c44 | 09:55 |
| programmerjake | basically 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 ones | 09:58 |
| programmerjake | renaming is the last step before getting people to review it and submitting it | 09:59 |
| programmerjake | unless you want to wait for potential po9 encodings of fcvt/fmv? | 10:00 |
| lkcl | ahh if it's following existing established conventions i'm fine with that (saw #43) | 10:05 |
| lkcl | rats, that's another thing on the list for the ISA WG, we have zero guidance on instruction naming conventions | 10:05 |
| programmerjake | ok, 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 variants | 10:09 |
| lkcl | yermermermerm... | 10:13 |
| lkcl | there's existing fpr-gpr move instructions?? | 10:14 |
| lkcl | ah no those are "pseudo-ops" | 10:15 |
| lkcl | we can't use them | 10:15 |
| lkcl | Extended mnemonic: Equivalent to: | 10:16 |
| lkcl | mtfprd FRT,RA mtvsrd FRT,RA | 10:16 |
| lkcl | p121 section 3.3.7 book I | 10:16 |
| lkcl | has to be separate instruction names. | 10:16 |
| lkcl | imagine the chaos of proposing an actual instruction to replace a pseudo-alias for the same thing | 10:17 |
| lkcl | plus | 10:17 |
| lkcl | it would become non-orthogonal | 10:17 |
| lkcl | how would Vectorisation of those instructions work? it couldn't | 10:18 |
| programmerjake | i'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 that | 10:20 |
| lkcl | no | 10:21 |
| lkcl | absolutely not | 10:21 |
| programmerjake | vectorization could work just fine since those are *scalar* instructions | 10:21 |
| lkcl | aside from anything it creates a hard-link at the Decode phase, onto VSX instruction decoding | 10:21 |
| lkcl | VSX 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 it | 10:22 |
| lkcl | and 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/SFFS | 10:22 |
| programmerjake | they can be called mfvsrd/mtvsrd in the actual proposal | 10:22 |
| lkcl | no | 10:23 |
| lkcl | no | 10:23 |
| lkcl | and no | 10:23 |
| lkcl | that's hard no: please listen | 10:23 |
| programmerjake | ah, ok. that will need to be mentioned as a motivating factor | 10:23 |
| lkcl | please make the effort to understand why i am saying "no" here | 10:23 |
| lkcl | ah there's some latency on IRC | 10:24 |
| programmerjake | takes a while for me to type on my phone | 10:24 |
| lkcl | it'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 |
| lkcl | aw doh :) | 10:24 |
| lkcl | and 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 |
| programmerjake | speaking of that, paul proposed an encoding for fp load immediate that imho should work well | 10:25 |
| lkcl | ahhh nice. i'm barely keeping up at the moment | 10:26 |
| programmerjake | when you want 32-bit immediates | 10:26 |
| programmerjake | i responded to him | 10:26 |
| lkcl | ok great. i'll catch it later, need water | 10:26 |
| programmerjake | i'll link to this conversation in the int/fp move one | 10:27 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:27 | |
| lkcl | good idea. | 10:28 |
| lkcl | i need to raise an issue on the ISA WG issue tracker about instruction-naming guidance | 10:29 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:30 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:40 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:43 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:04 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:05 | |
| markos_ | lkcl, check c12 on #1092, that's similar to what I had written, a 32-bit fp load immediate makes quite a difference | 12: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 value | 12:09 |
| markos_ | after all bf16 is fp32 shifted | 12:09 |
| markos_ | sadly that's not the same as fp16 | 12:10 |
| markos_ | hm, no, that's not going to work | 12:14 |
| markos_ | it needs a separate instruction | 12:14 |
| markos_ | a 16-bit value could be a bf16 with non-zero exponent, or a fp32 with zero exponent and clamped fraction parts | 12:15 |
| markos_ | in any case, I'd really like a 32-bit fp load immediate | 12:16 |
| markos_ | but a bf16 one is also useful ftm | 12:17 |
| ghostmansd[pc] | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/4350189 | 12:20 |
| ghostmansd[pc] | 5 failures vs 5 same failures on master | 12:20 |
| ghostmansd[pc] | merge? | 12:20 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.120> has joined #libre-soc | 13:05 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.120> has quit IRC | 13:10 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.120> has joined #libre-soc | 13:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.120> has quit IRC | 13:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:58 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:33 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:53 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:08 | |
| ghostmansd | merge! | 16:23 |
| ghostmansd | damn | 16:27 |
| ghostmansd | something's lost from commit | 16:27 |
| ghostmansd | hang on, I'm fixing it | 16:27 |
| ghostmansd | Yeah 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 |
| ghostmansd | Guys, let me know if you have any objections on adding more pysvp64db commands: https://bugs.libre-soc.org/show_bug.cgi?id=1094#c227 | 16:40 |
| ghostmansd | I 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 |
| ghostmansd | pysvp64db --help to the rescue! | 16:43 |
| ghostmansd | argparse generates help for us automatically | 16:44 |
| ghostmansd | I knew you'd be the first to ask :-) | 16:44 |
| markos_ | :) | 16:44 |
| markos_ | am I so predictable? :D | 16:44 |
| ghostmansd | Oh, 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 |
| ghostmansd | Nope, 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 help | 16:45 |
| ghostmansd | And 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 |
| ghostmansd | Not at all :-D | 16:46 |
| ghostmansd | Or, well, at least in a good sense! | 16:46 |
| ghostmansd | $ pysvp64db pcode addi | 16:46 |
| ghostmansd | RT <- (RA|0) + EXTS(SI) | 16:46 |
| ghostmansd | That's just one of examples of what might come handy | 16:47 |
| markos_ | this is nice | 16:47 |
| markos_ | I have already thought of a use case for this | 16:47 |
| markos_ | hm | 16:48 |
| markos_ | I'll think about it a bit more | 16:48 |
| markos_ | but we can get autogenerated visual representation of the instruction that way, eg. auto export a graphviz/dia code for a graph visualization | 16:49 |
| markos_ | long term | 16:50 |
| markos_ | btw | 16:54 |
| markos_ | do we categorize the instructions in any way? | 16:54 |
| markos_ | eg. addition, multiplication, shift, etc | 16:54 |
| markos_ | if we have something like that, we could do a tree-like representation | 16:54 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17: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 eventually | 17: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!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.230> has joined #libre-soc | 17: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@176.59.160.230> has quit IRC | 17:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.143> has joined #libre-soc | 17:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.172.143> has quit IRC | 18:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:00 | |
| *** tplaten <tplaten!~tplaten@62.144.58.35> has joined #libre-soc | 18:08 | |
| *** tplaten <tplaten!~tplaten@62.144.58.35> has quit IRC | 18:30 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:49 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:49 | |
| ghostmansd | I found that mdis should predate openpower-isa setup. Only revealed recently, when insndb/core.py had new walker class introduced. Symptoms: we run setup.py in openpower-isa and it fails due to yet unresolved mdis dependency. | 22:16 |
| ghostmansd | I couldn't find it before, because I already had mdis module installed in developer mode. | 22:16 |
| ghostmansd | The fix for hdl-dev-repos is committed, waiting for CI. | 22:17 |
| ghostmansd | Jacob, does CI track changes in dev-env-setup? | 22:18 |
| programmerjake | no, though i'm thinking of building a repo with autoupdated submodules for all our git repos so we can run ci on everything | 22:19 |
| programmerjake | mdis should be added to .gitlab-ci.yml in openpower-isa and soc, copy the code section for nmutil | 22:20 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22:24 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 22: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 |
| programmerjake | it'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 later | 22:30 |
| programmerjake | do remember to add mdis to soc.git too | 22:31 |
| programmerjake | if 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 mdis | 22:32 |
| ghostmansd | Hm. I've never used soc directly I think. Does it depend on openpower-isa? | 22:44 |
| ghostmansd | Ah wait, even if it does, it won't help. OK, I'll update it too. | 22:44 |
| programmerjake | soc depends on openpower-isa | 22:45 |
| programmerjake | since openpower-isa generates the decoder and has the test infrastructure and test cases and other stuff | 22:46 |
| programmerjake | hence why most openpower-isa tests are split between a class in a separate file and a top-level runner file | 22:47 |
| ghostmansd | FATAL: W any soc ghostmansd DENIED by fallthru | 22:48 |
| programmerjake | so soc can just import that class and run all tests on a simulation of libre-soc's hdl core | 22:48 |
| programmerjake | lkcl: ^ please grant ghostmansd access to soc.git | 22:48 |
| ghostmansd | Sorry Jacob, out of mana | 22:49 |
| programmerjake | ok, sleep well | 22:49 |
| ghostmansd | gn! | 22:49 |
| ghostmansd | thank you for your help again! | 22:49 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22: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 arguments | 23:27 |
| sadoon[m] | The more I dig into this, the less I understand it | 23:36 |
| rsc | IBM, who owns Red Hat, obviously needs to grow their revenue. Firing employees didn't make enough money. | 23:53 |
| rsc | Actually, it even might be a decision by Red Hat on its own, who knows. | 23:53 |
| rsc | Note, I am not a Red Hat employee, just a long-time free time/hobby contributor to Fedora and especially EPEL. | 23:54 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!