| *** kylel1 is now known as kylel | 07:10 | |
| Veera[m] | Hi | 10:58 |
|---|---|---|
| ghostmansd[m] | Hey | 11:32 |
| ghostmansd[m] | You must be looking for me :-) | 11:32 |
| ghostmansd[m] | I haven't time to check it yet, but I think this should work, based on my experience with dynamic loader | 11:32 |
| ghostmansd[m] | Libraries are in /use/local/lib, so adding this to ldso should be fine | 11:33 |
| ghostmansd[m] | I'm kinda surprised they don't use runpath though | 11:33 |
| lkcl | there's already an entry in /etc/ld.so.conf.d/libc.conf | 11:44 |
| lkcl | so it is not necessary to add it a 2nd time | 11:45 |
| Veera[m] | <ghostmansd[m]> "I'm kinda surprised they don't..." <- Benefit of shared libraries are binaries can use common installed library. | 11:46 |
| lkcl | ghostmansd[m], programmerjake, i'm often not at my laptop to be able to run budget-sync and use the bugtracker directly. if a bugreport "disappears" from searches because it's moved to "FIXED" that's very inconvenient for me | 11:46 |
| ghostmansd[m] | Veera[m], these are their libraries they install. This is not an argument. | 11:47 |
| Veera[m] | lkcl: https://bugs.libre-soc.org/show_bug.cgi?id=839#c6 | 11:47 |
| ghostmansd[m] | They do install these, therefore, they should set runpath appropriately, dot. | 11:48 |
| lkcl | by default anything that is installed in /usr/local/lib is *already covered* by the settings *already added* in /etc/ld.so.conf.d/libc.conf | 11:48 |
| lkcl | which is why i went "oink" that it didn't work | 11:49 |
| ghostmansd[m] | Apparently it's not, or, more likely, chroot has different ldso cache. | 11:49 |
| Veera[m] | ghostmansd[m]: Purpose of /etc/ld.co.conf and linux, libc dynamic linker is the keep txt data of library paths | 11:49 |
| ghostmansd[m] | Veera[m], I know it, thanks for pointing it. | 11:49 |
| lkcl | ahhh i just ran ldconfig manually in your chroot directory and the problem's "fixed" | 11:50 |
| Veera[m] | Whereas -rpath and -runpath have to be explicitly specified while compiling the program. gcc and linker! | 11:50 |
| ghostmansd[m] | Again: when you install sw with its libraries, you must take sure they can work together. Especially if you give a way to install to special location. | 11:50 |
| Veera[m] | yes. somehow I missed! | 11:51 |
| ghostmansd[m] | User should not care less to edit something on their own. | 11:51 |
| lkcl | so yes running ldconfig from inside the script is the correct solution here | 11:52 |
| ghostmansd[m] | This should come from --prefix. libtool or what they use nowadays, it should handle it. | 11:52 |
| ghostmansd[m] | Or, well, ldconfig should be run from install script. | 11:52 |
| lkcl | can someone confirm these messages are getting through, my internet connection is extremely dodgy | 11:52 |
| ghostmansd[m] | But my point is, it's strange we have to do what binutils makefile was supposed to do. | 11:53 |
| ghostmansd[m] | lkcl, I see these. | 11:53 |
| Veera[m] | Little GNU concept is flexibility | 11:53 |
| lkcl | ghostmansd[m], ok whew. HTTP is currently disconnected (!) | 11:53 |
| lkcl | i have had it necessary in the past to explicitly run ldconfig to get ld.so.cache updated when installing software into /usr/local/lib | 11:54 |
| lkcl | it happens (in)frequently enough to for me to recognise the solution (just run ldconfig) | 11:55 |
| ghostmansd[m] | Ok, as long stuff works, I'm fine. | 11:55 |
| Veera[m] | I have done Linux Distribution building from scratch and most gnu and allied friends do only this way. We have to explicitly run ldconfig. | 11:55 |
| lkcl | but not frequently enough that i totally remember: i actually ran "ldconfig -p" yesterday which just lists the cache :) | 11:55 |
| ghostmansd[m] | Well, I also recall that some makefiles even print this reminder to run it. | 11:55 |
| ghostmansd[m] | Ok, let's have it in script then. | 11:56 |
| Veera[m] | yep | 11:56 |
| Veera[m] | lkcl: Is there some more to do from my side for Bug #839 | 12:00 |
| lkcl | Veera[m], the page looks really good, now. | 12:04 |
| Veera[m] | thanks. | 12:05 |
| lkcl | i really need to do one more diagram | 12:05 |
| lkcl | at least | 12:05 |
| Veera[m] | lkcl: is there some other work for me? | 12:06 |
| Veera[m] | I remember other images to be converted to svg. | 12:07 |
| lkcl | yes give me about half an hour i'll draw another diagram | 12:07 |
| Veera[m] | While I was passing through ml someone else was alloted. | 12:08 |
| Veera[m] | lkcl: ok | 12:08 |
| lkcl | Veera[m], done, just need to upload it | 12:24 |
| lkcl | https://ftp.libre-soc.org/20220614_122128.jpg | 12:26 |
| lkcl | sorry, camera managed to get it upside-down :) | 12:26 |
| lkcl | Veera[m], i'm just going to do a Matrix-Multiply one as well | 12:36 |
| lkcl | Veera[m], done | 13:21 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=839#c8 | 13:21 |
| ghostmansd[m] | A strange question on registers. Are we allowed to mix scalars and vectors? If not, why do we have to explicitly put .s and .v? | 18:18 |
| ghostmansd[m] | I mean, couldn't it be the operation mode as well? | 18:18 |
| ghostmansd | OK I think I've found where to enter this gory parsing and lexing mess :-) | 18:43 |
| ghostmansd[m] | Also, is it OK if I submit PPC draft instructions to the review? | 19:44 |
| ghostmansd[m] | Ah I recalled there's no agreement on grevX insns. | 19:45 |
| lkcl | ghostmansd[m], yes they're allowed to be mixed. | 20:26 |
| lkcl | that's why there's multiple EXTRAs | 20:26 |
| lkcl | EXTRA_IDX0/1/2/3 | 20:26 |
| ghostmansd[m] | Ok then, this will need some tuning on parsing side too then :-) | 20:27 |
| lkcl | the better ones to submit would be setvl, svstep, svshape and svremap. | 20:27 |
| lkcl | mhm :) | 20:27 |
| ghostmansd[m] | In fact, I'm happy, since parts of code I wrote go down the drain | 20:27 |
| lkcl | deep joy! | 20:27 |
| ghostmansd[m] | That's the best that can happen to code | 20:27 |
| lkcl | basically the way that Vector ISAs uuusually work is: | 20:28 |
| lkcl | you have VSPLAT instructions (a "broadcast" of a Scalar to a Vector) | 20:28 |
| lkcl | VINSERT instructions (an "insert" of a scalar into a vector) | 20:28 |
| lkcl | VEXTRACT (an "extraction" of a scalar from a vector) | 20:28 |
| lkcl | VREDUCE/VCOMPRESS (pass a predicate mask 0b10011111001 and you "compress" the vector elements where there are 0s) | 20:29 |
| lkcl | so in the "VSPLAT" category, you can have "add this scalar to all vector elements" | 20:30 |
| lkcl | add vector_result, scalar_source, vector_source | 20:30 |
| lkcl | but you could also have | 20:30 |
| lkcl | add vector_result vector_source, scalar_source | 20:30 |
| lkcl | okok that makes more sense when it's a subtract | 20:31 |
| lkcl | sub r.v, s1.v, s2.s or | 20:31 |
| lkcl | sub r.v, s1.s, s2.v | 20:31 |
| ghostmansd[m] | Aaah ok, now it's clear | 20:31 |
| ghostmansd[m] | Thanks! | 20:31 |
| lkcl | in SVP64 we decided to use the *suffix* as the way to specify that, in a "general" form | 20:31 |
| lkcl | and it turns out that when you have a predicate mask with a single bit, mask=0b0000010000 | 20:32 |
| lkcl | and you apply that to something with a *scalar result*, you can perform VEXTRACT | 20:32 |
| lkcl | sv.add/mask=0b000010000 r.scalar, s1.v, s2.v | 20:32 |
| lkcl | or EXTRACT-like | 20:33 |
| lkcl | so that turns a single "scalar add" into *EIGHT* possible Vector instructions! | 20:33 |
| lkcl | s s s | 20:33 |
| lkcl | s s v | 20:33 |
| lkcl | s v s | 20:33 |
| lkcl | s vv | 20:33 |
| lkcl | v s s | 20:33 |
| lkcl | ... | 20:33 |
| lkcl | v v v | 20:33 |
| lkcl | !! | 20:33 |
| lkcl | if you have four operands it's *sixteen* possible vector instructions! | 20:34 |
| lkcl | which is where you start to appreciate how 214 Power ISA 3.0SFFS Compliancy Level instructions managed to turn into an astonishing 1.5 *MILLION* | 20:34 |
| ghostmansd[m] | Neat | 20:35 |
| lkcl | neat, he calls it. it's more like "totally insane" :) | 20:36 |
| lkcl | there's not a single ISA in the world with 1.5 *MILLION* Vector instructions | 20:36 |
| ghostmansd[m] | Well I came from x86 camp, there were horrible design choices as well :-) | 20:36 |
| ghostmansd[m] | I'm impressed, but I've seen some shit :-) | 20:36 |
| ghostmansd[m] | Dammit binutils don't like these dots at .s and .v | 20:37 |
| ghostmansd | .set fv0, 32 | 20:38 |
| ghostmansd | lfs fv0.v, 256(win) | 20:38 |
| ghostmansd | From binutils point of view, fv0.v is a single lexem (unsurprizingly) | 20:38 |
| lkcl | yyep. surpriiise | 20:38 |
| lkcl | wait... you mean sv.lfs fv0.v, 256(win) | 20:39 |
| lkcl | you *must* not permit "lfs fv0.v" to work as a scalar instruction | 20:39 |
| lkcl | that's critically important to have that throw a syntax error | 20:39 |
| ghostmansd | yeah | 20:39 |
| ghostmansd | sorry :-) | 20:39 |
| lkcl | :) | 20:40 |
| ghostmansd | posted after the opmodes were discarded by my routines | 20:40 |
| ghostmansd | I'm trying to move all parsing except for opmodes to binutils | 20:40 |
| ghostmansd | and that's quite a painful activity | 20:40 |
| lkcl | cesar, programmerjake toshywoshy jn rsc markos lxo excited-mango[m] meeting 10m | 21:48 |
| lkcl | kanzure, if you're interested i'll pm you a link | 21:48 |
| programmerjake | k | 21:48 |
| lkcl | sadoon[m], i'm assuming you're asleep due to getting up for work at a reasonable hour :) | 21:50 |
| sadoon[m] | Hey :) | 21:50 |
| sadoon[m] | I'll be sleeping soon but not yet | 21:50 |
| sadoon[m] | Might join for a bit | 21:50 |
| ghostmansd[m] | I guess I'll try joining too | 21:55 |
| ghostmansd[m] | Would be great if someone could PM login/pass | 21:56 |
| ghostmansd[m] | Ah there's no Russia number. I guess I won't be able to attend. | 22:05 |
| ghostmansd[m] | Not even a slightest idea how to join. | 22:05 |
| programmerjake | you should be able to join using webrtc using the webpage in chromium -- firefox is somehow borked | 22:10 |
| programmerjake | sent you the link via PM ghostmansd | 22:10 |
| ghostmansd | thanks programmerjake! this one I had :-) | 22:11 |
| ghostmansd | looks like I managed to join :-) | 22:13 |
| programmerjake | :) | 22:18 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
