Friday, 2023-03-03

*** ghostmansd[m] <ghostmansd[m]!> has quit IRC01:22
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC01:42
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc01:43
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc01:50
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:06
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc02:06
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC02:30
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:36
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc02:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC03:21
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:15
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:16
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:32
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC04:42
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc05:04
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC05:22
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc05:40
*** Ritish <Ritish!~Ritish@> has joined #libre-soc05:48
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:44
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:49
lkclprogrammerjake, please do make sure to keep meticulous records in - put copies of the commit log message(s)10:19
lkclthe EUR 100,000 NLnet Grants are *definitely* going to be audited.  they have been specially assigned an EU Auditor10:19
lkcli'll cover that it's *five* new instructions, now, not four.10:20
programmerjakek, though because dsld/dsrd with Rc=1 are 4-in/4-out iirc we wanted to remove Rc=1 mode for dsld/dsrd. i can probably do that friday if that sounds good10:24
lkcl3-in 2-out-plus-CR010:26
lkclthey're not 4-in 4-out.10:27
programmerjake4-in: RA, RB, RC, SO 4-out: RS, RT, CR0, SO/OV[32]10:28
lkclthe programmer's note for maddedus is a nice touch. good explanation.10:28
lkclone reason i want to keep the overflow thing is, if you imagine using Data-Dependent Fail-First and there's a "queue" (large vectorised shift register), and you want things to stop when the data is zero or non-zero10:31
lkclVL effectively becomes a counter of when a zero (or non-zero) cropped up10:31
lkclbetter hope that the 5-bit DD-FF can be used for that!10:32
programmerjakethen imho change it to 3-in/3-out -- set to what overflow is now but don't read/write or xer.ov[32]10:32
programmerjakein the numbered notes/observations list, both 1. and 2. basically explain why divmod2du has no Rc or OV form, but then dsld/dsrd go on to ignore that completely...imho divmod2du having overflow output is much more justifiably useful than dsld/dsrd because there are known algorithms that need that overflow info (Knuth algo D)10:39
lkcldivmod2du puts EXT004 under pressure.  i don't mind as long as space can be found.10:41
lkclbut i want this "in" and submitted because i need an RFP10:42
lkcland i want to encourage the OPF ISA WG and IBM to make useful constructive comments10:42
lkcland other OpenPOWER Members10:42
programmerjakemaybe add this as a unresolved question for the isa wg, specifically writing it in notes/observations? most other RFC formats i've seen have something like that (assuming they're actually requesting comments and not just publishing something)10:44
programmerjakeif you add that, i'm fine with the rest as-is10:45
lkclok willdo10:45
programmerjakewas hoping you'd specifically mention removing Rc=1 from dsld/dsrd or adding OV to divmod2du, but good enough since you can explain in person10:51
lkclgimme a sec to just cross-reference this conversation into the (private) ISA WG bugtracker...10:55
programmerjakek, since it's 3am here, gn ttyl10:58
lkclaright jk.11:18
*** Ritish <Ritish!~Ritish@> has quit IRC11:28
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc11:52
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC14:34
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:36
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:49
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:50
sadoon[m]<toshywoshy> "sorry, that is the wrong line..." <- Thanks for that, one sec will explain better what happened with me16:10
sadoon[m]<programmerjake> "imho we need a new triple..." <- agree with that at least16:11
sadoon[m]<markos> "it's hard, but definitely doable" <- not hard, will explain in a sec16:12
sadoon[m]Alright, finished catching up here16:14
sadoon[m]1- I used "-mlong-double-64" specifically because C++ software fails to build on power9, power8, and power7 without 128-bit long doubles16:14
sadoon[m]After that I learned that we are not supporting 128-bit float anyways16:15
sadoon[m]So in addition to your flags, this is necessary16:15
sadoon[m]As soon as you disable altivec and/or vsx, gcc will complain16:15
sadoon[m]I assume the same for clang, in fact let me test now16:16
sadoon[m]Hmm nevermind, clang is smart enough I guess16:19
sadoon[m]Or it's just enabling float128?16:19
sadoon[m]Anyways, will test on a qemu e6500 which should not have float128 in little endian16:19
sadoon[m]2- re: runtime detection16:20
sadoon[m]#ifdef __BUILTIN_CPU_SUPPORTS__16:20
sadoon[m]                if (__builtin_cpu_supports ("vsx"))16:20
sadoon[m]easy stuff16:20
sadoon[m] Not the latest docs but there's probably newer ones that document this too16:21
*** gnucode <gnucode!~joshua@user/jab> has joined #libre-soc16:51
gnucodelkcl: hey I got your email!  I'm pretty sure that it'll be your friend with powerEL that will get the board.  So far no one else seems as interested as you two in it, and if you say that he's got the expertise and the FSF does not, then I believe you.  :)16:52
gnucodeI actually get to play with the talos II for two weeks while he is on vacation.  I am open to any and all tips that you might have.  :)16:53
lkclgnucode, well - they might have, and they should go to the trouble of responding immediately to inform you of that16:55
lkclooOoo :)16:55
lkcljoin #talos-workstation16:55
gnucodelkcl I am there now.  :)16:59
lkcllots of well-informed people on there, actively running TALOS-II machines16:59
gnucodethanks!  I hope the libre-soc project is going swell!17:00
markossadoon[m], runtime detection isn't as easy, what you wrote basically just checks if at compile-time cpu support VSX17:21
sadoon[m]Oh silly me17:21
sadoon[m]Oh wait no, this is a regular if function though?17:21
sadoon[m]So technically you can use it at runtime too?17:22
markosfor runtime detection you need to have a way to check at *runtime* if your cpu actually supports a particular instruction, in the past people executed an eg VSX instruction and if it didn't they trapped the result, however nowadays we use HWCAP17:22
markosyou have to check the cpu features as reported by the kernel17:22
markosofc if you're using glibc, there is this ifunc feature17:23
markoswhere you declare all versions of a function with separate ifunc attributes17:23
sadoon[m]How does this if statement check then?17:23
markossorry, it's function multiversioning17:25
markosso you define the same function using the appropriate attribute17:26
programmerjakeaccording to the gcc docs, __builtin_cpu_supports does *runtime* detection
markosin our case, we should have a regular C implementation (sffs), "vsx", "svp64", etc17:26
markoshm, I misread it then, you are correct, apologies,17:28
markoswell, even better, pick a method17:28
sadoon[m]yep :D17:28
markoshowever, this is gcc-specific17:28
gnucodesadoon[m]: you're working on the libre-soc project too?  that's awesome!17:28
sadoon[m]we can check if clang supports something similar?17:29
sadoon[m]gnucode: thanks :)17:29
markossadoon[m], reg. the triplet, personally at this moment I wouldn't go there,17:30
sadoon[m]Yeah I agree17:31
markossadoon[m], the only thing you gain is added complexity for all packages17:31
programmerjakeimho use the icr-the-name feature that resolves which fn (where you can put cpu feature detection since it can be slow) to use the first time it's called then all future calls call the resolved-to fn17:31
markosand in the end, we don't need another port, just a port with different defaults, which should also be backwards compatible17:31
markosat least on the same platform I mean17:32
markosobviously an svp64 can not run the old ppc64le port17:32
markoshowever the vsx one should be able to run the same binaries without any change17:32
markosbut a new release should be able to run on both systems, and with proper runtime detection pick the appropriate runtime17:33
programmerjakeone issue is the ABI for some types *requires* vsx even though those types can and should be software emulatable, e.g. __float12817:35
programmerjakeactually just vmx17:35
programmerjakeso imho that's part of why we need eabi 3.017:37
programmerjakeeabi 3.0 can be designed to be able to be installed on a system simultaneously with eabi 2.x, e.g. by using a different path17:38
programmerjakeso old binaries run with native/emulated vsx support17:39
markosthat's not surprising, hardware float128 was a wishlist ticket for a long time and the only way to do it was to use vmx registers17:40
markosvmx so that it can be used in BE as well17:40
markosin any case, what I mean is that we don't have to change the triplet for a future port that will support both systems17:43
markosI don't see how power is different in that case than arm for example17:43
markosthey have multiple features per cpu, SVE, SVE2, ASIMD, etc, but only a single triplet for 64-bit systems aarch64-linux-gnu17:44
markosdon't underestimate the unneeded complexity of having to add extra entries in thousands of packages17:45
toshywoshythe triplets should reflect the isa compliancy subsets17:52
toshywoshyin that way we would have the following17:52
toshywoshy1. powerpc64-linux-gnu (big endian subset)17:52
toshywoshypowerpc64le-iinux-gnu (little endian subset)17:53
toshywoshypowerpc64sffs-linux-gnu (sffs subset)17:53
toshywoshypowerpc64sfs-linux-gnu (sfs subset)17:53
toshywoshyeven though I think the last will be nearly never used17:54
toshywoshythe part I was talking about was gcc -march, which is different and we should think the same way as arm/x64 does17:55
markossffs can be also either LE or BE as well right?17:56
toshywoshywell, yes, sffs can be BE or LE17:57
markosin any case, what I'm suggesting here is essentially merging powerpc64sfs-linux-gnu triplet back into powerpc64le-iinux-gnu17:57
toshywoshyso in fact, we should have powerpc64sffsle and powerpc64sffsbe17:58
markosor powerpc64-linux-gnu for BE for that matter17:58
markosbasically changing the baseline, without changing the triplet17:58
markosas you said, sfs plain is probably not going to be used17:58
toshywoshyI am not sure we can do that, but if we do not need to create a triplet, that would be better17:59
markosit should definitely be possible, for existing platforms nothing would change17:59
markoseg. power917:59
markosfor newer platforms they just wouldn't be able to run "old" distros17:59
markosbut that would be expected anyway18:00
toshywoshyno but if we have a libresoc core with just sffs?18:00
markossffs would be enabled, just with the same triplet18:00
markoslet me be more specific with an example18:01
programmerjakeimho supporting sfs is useful for embedded linux18:01
markosdebian 12 is about to be released, this will use existing abi with VSX by default, triplet  powerpc64le-iinux-gnu18:01
markoslet's say this change is implemented in debian 14, abi changes to newer one, where VSX is now optional, and SFFS is the default18:02
markossame triplet18:02
toshywoshythat is not where the problem comes into effect18:03
toshywoshyif by debian14 we have different cores that can do SFFS, LE, BE18:03
toshywoshyhow would this play out18:03
markospower9 systems will be able to just install d14 without problems and all software will not have to be modified in its configure scripts -but it will have to be rebuilt18:04
markosotoh, d14 that is installed on a libresoc system, either BE or LE, will install the same installers as power918:05
toshywoshyand would crash18:05
markosbecause SFFS will be the baseline18:05
markosthat's what I'm saying18:05
markosIF SFFS is the baseline, it will work everywhere18:05
markoseven on power918:05
markosit will just not use VSX and underperform18:06
toshywoshyso the powerpc64 and powerpc64le change from the current baseline to SFFS subset18:06
toshywoshyah, ok, and then we use the IF INCLUDE18:06
markosat that point VSX will be optional and glibc will just load the appropriate optimized VSX functions on Power9 with function multiversioning18:07
markosas Arm is currently doing for SVE2 optimized glibc functions18:07
markosand Intel18:07
toshywoshyok, in that case, we indeed do not need an additional triplet18:07
markosand at the same time SVP64 will do the same on LibreSOC18:07
toshywoshybut then the question is whether we want to go for a baseline of SFFS or SFS18:07
markosthat's another question18:08
toshywoshyI haven't actually put time into how different SFS is from SFFS18:08
markosif SFFS is not the baseline, then indeed SFS should be used instead18:08
programmerjakewe do need an abi break for f128, since we need f128 softfloat support but the current abi requires vmx regardless18:09
toshywoshyeabi is set by opf and we can influence that, once we have a use case, so I am not too worried about that18:10
programmerjakeif we don't have sffs as the baseline then the abi would need to require passing all fp values on the stack or in gprs, imho that's too inefficient, so sfs should not be the baseline for e.g. debian18:13
programmerjakeimho sfs should be like Raspbian in that you need a custom distro specifically for it, all general purpose distros should assume sffs18:15
toshywoshyif we change the baseline, we need to change it to something that makes sense to 95% of the use cases so we cover nearly all cases18:17
programmerjakeor, more specifically should assume the intersection of v3.0c sffs and whatever cpu first supported ppc64le (power7?)18:17
toshywoshyso if we think again about powerpi, I would want debian/fedora/powerel on that18:17
programmerjakeare you expecting the powerpi to have fp? i hope yes...18:18
toshywoshyyes, floating point would be included18:19
programmerjakeif yes i expect it'll support sffs intersect ppc64le18:19
programmerjakeso no need for sfs baseline there18:20
*** gnucode <gnucode!~joshua@user/jab> has quit IRC18:23
rscAre you referring to glibc hwcaps to avoid custom distributions?18:24
markosprogrammerjake, the only problem you will have with float128 is with old apps that one might try on a libresoc, and I don't think those will be many, newer apps in distros or elsewhere would just be recompiled with the new abi and run correct everywhere18:24
markosI think the list of those is very small though18:24
lkcltoshywoshy, SFS is 150 instructions, specifically excluding all FP operations. SFFS is 214 and specifically includes all FP scalar operations18:24
markospersonally I agree that sffs should be the baseline for everything18:24
markosand it makes sure that the port will run in all future cpus with no change18:25
markosand many old ones18:25
toshywoshylkcl: yes, that much I remember by heart, I do not remember the details18:25
programmerjakeimho the main issue we'll run into is binary libraries with the old abi that people try to link stuff in the new abi to18:25
markoswe can easily disable that18:26
markosit's not like power is full with old legacy software that one would want to use on a newer system, this is not x8618:27
markosI would tackle those cases when/if they come18:27
lkclprogrammerjake, a new ABI has already been very specifically vetoed by paul mackerras.18:29
lkclproposals to design anything other than an EABI which are not specifically and exactly and precisely what was in EABI 1.5 will be met with a "no"18:30
lkclyou have been told this already. i am reminding you of it for the second time18:30
programmerjakebut debian/etc. doesn't use eabi 1.518:31
markosno they don't18:31
markoswe cannot go to 1.5, that's a definite negative, but we can look at what it does and "borrow" the same mechanism and fix our EABI to do the same18:32
programmerjakewell, that's a breaking change so that becomes eabi 3.018:32
programmerjakeunless the eabi doesn't follow semver18:33
toshywoshywell, the version number, will use semver, so I suspect it to be 3.0, but that is a detail, the number will be decided after we get the eabi defined18:34
toshywoshybreaking changes will make the major number increase18:35
programmerjakeso, since it's breaking, imho we fix f128 abi to not require vsx while we have the chance18:35
programmerjakef128 isn't in eabi 1.518:35
programmerjakeso imho our options are make debian/fedora/etc. use eabi 1.5 (not happening), create minimal vsx subset that's just registers, moves, and loads/stores for abi compat (unlikely), create eabi 3.0 without vsx/vmx, add full vsx to every cpu that wants to run debian (unlikely)18:42
markosthere is only one solution really18:42
markoseabi 3.0 w/o vsx/vmx18:43
markosor whatever version number that's going to be18:43
programmerjakeminimal vsx subset might actually work18:43
markosonly if it's an emulated one18:43
markostbh I wouldn't even bother with that18:44
programmerjakeminimal vsx subset *in hw*18:44
markosI honestly don't see a problem18:45
markosthe apps affected will be minimal18:45
markosand the problem will only manifest on cpus that do NOT have VSX and try to use OLD apps that use float128 instructions18:45
markosall new apps would have the new abi18:45
markoss/have/be rebuilt/18:45
programmerjakenot even float128 insns, anything using softfloat f128 at all18:46
markoseven those18:47
markosthe problem is easily fixable in our case, because we control both hardware and software18:47
markosthe chances of someone running an old *binary* app that uses float128 on a libresoc are probably close to zero18:48
markosmost likely it will be a distro app and we will just recompile with the new abi, problem solved18:48
markoswe will have to recompile the world anyway18:49
programmerjakewould require fixing llvm and gcc and all other code that does diy abi stuff (libffi-style), currently gcc doesn't seem to work at all and llvm does idk what, probably accidental18:50
markosyes ofc, changing the abi implies fixing the compilers as well :)18:50
programmerjakellvm appears to default to passing f128 in a pair of int regs when -mno-altivec is given:
markosso all good then18:57
programmerjakeno, afaict it's completely accidental and may not be consistent, we'll need to ensure it matches whatever the eabi 3.0 says18:59
markosI don't think it's accidental, if -mno-altivec is used then there are no VMX registers available and the compiler *has* to use GPRs19:00
markosand I bet softfloat128 code is inserted for the operations19:00
programmerjakei'd expect llvm just does whatever random thing was easiest at the time, with no thought for abi compatibility at all.19:01
programmerjakeit does call softfloat functions, but afaict those functions take arguments and return values in vmx regs so there's an abi mismatch19:02
markosI sincerely doubt that, something like that would get caught immediately, -mno-altivec has been used extensively for the powerpc port to make sure it runs on old cpus without altivec19:02
programmerjakebut those use the old eabi, -mno-altivec still uses eabi 2.0 here which says "use vmx regs"19:03
programmerjakethe old eabi says nothing at all about f128, i checked19:03
markosthe mechanism of passing values through the vmx registers I meant, even with -mno-altivec, this is not a new thing19:05
markosin any case, if llvm does this, it's quite likely that gcc will also do something similar, if not then it's definitely a bug19:05
programmerjakeafaict previously vmx regs were only used for vmx types, all other types used fprs/gprs/stack19:06
programmerjakeafaict gcc just disables f128 type support completely19:06
markoswell, float128 is special and ibm-only19:06
markosin hardware I mean19:06
markoseveryone else does it in software19:07
programmerjakefloat128 is supported in the ABI on many other arches19:07
markosas a type yes, but it's all emulated19:07
markosand passed through GPRS19:07
markosor stack19:07
programmerjakeno, on x86-64 iirc it's passed in sse regs19:08
markosafaik there is no other platform with hardware float128, integer 128-bit yes19:08
markosbecause x86-64 assumes SSE2 iirc19:08
programmerjakeuuh, zseries and riscv have hw f128 iirc19:08
markosok, the first is IBM and the other is a brand new arch with a fluid ABI, not much is set in stone yet19:09
markosin any case19:09
markosmy point is that I don't think it's an accident19:09
markosI think it's doing the right thing and in that case, this is a non-issue then19:10
markosbecause if it's passing the values in GPRs/stack then there is no ABI that needs to be "fixed" in that regard, because it's already working19:11
programmerjakek, well gcc is definitely not doing what we want, no f128 whatsoever19:11
markosok, good19:12
markosit is actually doing exactly what we want19:12
markosit does not cause a problem19:13
programmerjakeexcept sw expects to have the __ieee128 type and it isn't there so the sw fails to compile, iirc sadoon was running into this issue19:14
programmerjakeso it is a problem19:14
markosif the software fails to compile that's not our problem at all19:15
markosthe problem is with compiled software with the wrong assumptions and using VSX registers that would eventually run in a CPU without VSX19:16
markosthis is a compiler problem, not an EABI problem, or actually it's the problem of the software itself19:16
markosand most likely easily fixable19:17
programmerjakei disagree, imho it's like if some arch randomly decided that it has no wchar_t type just cuz it wants wchar_t to use special utf-32 insns19:17
markoswchar_t type is NOT arch specific19:17
markosfloat128 is19:17
programmerjakethe sw wants __float128 and doesn't care if it's sw emulated19:17
programmerjakeand iirc __float128 is available on basically every arch in gcc thanks to libquadmath19:18
markos__ types are not the default C types, but the compiler primitives, people should know this and fall back to the software emulation if the __float128 type is not available19:18
markosie software19:19
programmerjakebut you're missing my point, gcc provides that sw emulation through the __float128 type19:20
markosbut it's a gcc-ism19:20
markosif it's sw-emulated then it's definitely NOT using the VMX registers19:20
programmerjaketrue, but any decent compiler on linux supports those gcc-isms19:20
markosso there is no problem19:21
programmerjakeit *is* using vmx because that's what the abi says regardless of if you're using the f128 insns or not19:21
markosyou just said it cannot even use the f128 types if -mno-altivec is passed19:22
programmerjakeyes, because gcc doesn't really support -mno-altivec on eabi 2.019:22
programmerjakeno f128 types is a symptom of no gcc support19:23
markosok, I think we're talking passed each other, we care only about -mno-altivec here, we don't care what the current ABI does19:23
markosif the software absolutely needs f128 support from gcc then they have to file a bug report to gcc to add that support even with -mno-altivec19:24
markosor use clang/llvm which seems to just use software float12819:24
programmerjakewhat i care about is gcc regaining support for f128 with -mno-altivec and *being 100% compatible* with clang19:25
markosno, we don't care about this at this point19:25
markosit really is a very very small issue19:25
markosif gcc still hasn't after all this years become 100% compatible with clang, even if IBM has already so many compiler engineers working on both compilers19:26
programmerjakewell, i think we've got our points across and further arguing is pointless19:26
markosthen either they don't care, or there is a good reason for ti19:26
markosbut fixing the compilers for OLD EABIs, sorry, but I'm pretty strong-opinioned about this, it's none of our business, and it's completely beyond our scope19:28
programmerjakeimho they could care less about -mno-altivec on eabi 2.0 since it's a logical contradiction19:28
programmerjakeexcept maybe for the linux kernel abi where all fp regs are off limits19:29
programmerjakewell ttyl19:30
*** octavius <octavius!> has joined #libre-soc19:32
octaviuslkcl, saw your new bug 1013. What about ls001/002?19:33
sadoon[m]Unrelated, but19:40
* sadoon[m] is tired trying to build qtwebengine for G519:40
sadoon[m]If only KDE was not so reliant on it :(19:41
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC19:58
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc19:59
*** octavius <octavius!> has quit IRC20:25
*** octavius <octavius!> has joined #libre-soc20:45
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc21:41
*** octavius <octavius!> has quit IRC22:07
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC23:20
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc23:21
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC23:30
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc23:54

Generated by 2.17.1 by Marius Gedminas - find it at!