| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 01:22 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 01:42 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 01:43 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 01:50 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:06 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 02:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 02:30 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:36 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 02:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:21 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:15 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 04:16 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 04:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 05:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:40 | |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has joined #libre-soc | 05:48 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:43 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:49 | |
| lkcl | programmerjake, please do make sure to keep meticulous records in https://bugs.libre-soc.org/show_bug.cgi?id=1010 - put copies of the commit log message(s) | 10:19 |
|---|---|---|
| lkcl | the EUR 100,000 NLnet Grants are *definitely* going to be audited. they have been specially assigned an EU Auditor | 10:19 |
| lkcl | i'll cover that it's *five* new instructions, now, not four. | 10:20 |
| programmerjake | k, 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 good | 10:24 |
| lkcl | 3-in 2-out-plus-CR0 | 10:26 |
| lkcl | they're not 4-in 4-out. | 10:27 |
| programmerjake | 4-in: RA, RB, RC, SO 4-out: RS, RT, CR0, SO/OV[32] | 10:28 |
| lkcl | the programmer's note for maddedus is a nice touch. good explanation. | 10:28 |
| programmerjake | thx! | 10:29 |
| lkcl | one 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-zero | 10:31 |
| lkcl | VL effectively becomes a counter of when a zero (or non-zero) cropped up | 10:31 |
| lkcl | better hope that the 5-bit DD-FF can be used for that! | 10:32 |
| programmerjake | then imho change it to 3-in/3-out -- set cr0.so to what overflow is now but don't read/write xer.so or xer.ov[32] | 10:32 |
| programmerjake | in 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 |
| lkcl | divmod2du puts EXT004 under pressure. i don't mind as long as space can be found. | 10:41 |
| lkcl | but i want this "in" and submitted because i need an RFP | 10:42 |
| lkcl | and i want to encourage the OPF ISA WG and IBM to make useful constructive comments | 10:42 |
| lkcl | and other OpenPOWER Members | 10:42 |
| programmerjake | maybe 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 |
| programmerjake | if you add that, i'm fine with the rest as-is | 10:45 |
| lkcl | ok willdo | 10:45 |
| programmerjake | was hoping you'd specifically mention removing Rc=1 from dsld/dsrd or adding OV to divmod2du, but good enough since you can explain in person | 10:51 |
| lkcl | gimme a sec to just cross-reference this conversation into the (private) ISA WG bugtracker... | 10:55 |
| lkcl | done | 10:58 |
| programmerjake | k, since it's 3am here, gn ttyl | 10:58 |
| lkcl | aright jk. | 11:18 |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has quit IRC | 11:28 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.164> has joined #libre-soc | 14:36 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.41.164> has quit IRC | 14:49 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:50 | |
| sadoon[m] | <toshywoshy> "sorry, that is the wrong line..." <- Thanks for that, one sec will explain better what happened with me | 16:10 |
| sadoon[m] | <programmerjake> "imho we need a new triple..." <- agree with that at least | 16:11 |
| sadoon[m] | <markos> "it's hard, but definitely doable" <- not hard, will explain in a sec | 16:12 |
| sadoon[m] | Alright, finished catching up here | 16: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 doubles | 16:14 |
| sadoon[m] | After that I learned that we are not supporting 128-bit float anyways | 16:15 |
| sadoon[m] | So in addition to your flags, this is necessary | 16:15 |
| sadoon[m] | As soon as you disable altivec and/or vsx, gcc will complain | 16:15 |
| sadoon[m] | I assume the same for clang, in fact let me test now | 16:16 |
| sadoon[m] | Hmm nevermind, clang is smart enough I guess | 16: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 endian | 16:19 |
| sadoon[m] | (later) | 16:19 |
| sadoon[m] | 2- re: runtime detection | 16:20 |
| sadoon[m] | #ifdef __BUILTIN_CPU_SUPPORTS__ | 16:20 |
| sadoon[m] | if (__builtin_cpu_supports ("vsx")) | 16:20 |
| sadoon[m] | easy stuff | 16:20 |
| sadoon[m] | markos | 16:21 |
| sadoon[m] | https://devdoc.net/c/gcc_7.2/PowerPC-Built_002din-Functions.html Not the latest docs but there's probably newer ones that document this too | 16:21 |
| *** gnucode <gnucode!~joshua@user/jab> has joined #libre-soc | 16:51 | |
| gnucode | lkcl: 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 |
| gnucode | I 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 |
| lkcl | gnucode, well - they might have, and they should go to the trouble of responding immediately to inform you of that | 16:55 |
| lkcl | ooOoo :) | 16:55 |
| lkcl | join #talos-workstation | 16:55 |
| gnucode | lkcl I am there now. :) | 16:59 |
| lkcl | awesome | 16:59 |
| lkcl | lots of well-informed people on there, actively running TALOS-II machines | 16:59 |
| gnucode | thanks! I hope the libre-soc project is going swell! | 17:00 |
| markos | sadoon[m], runtime detection isn't as easy, what you wrote basically just checks if at compile-time cpu support VSX | 17:21 |
| sadoon[m] | Oh silly me | 17: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 |
| markos | for 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 HWCAP | 17:22 |
| markos | nope | 17:22 |
| markos | you have to check the cpu features as reported by the kernel | 17:22 |
| markos | ofc if you're using glibc, there is this ifunc feature | 17:23 |
| markos | where you declare all versions of a function with separate ifunc attributes | 17:23 |
| sadoon[m] | How does this if statement check then? | 17:23 |
| markos | sorry, it's function multiversioning | 17:25 |
| markos | https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html | 17:26 |
| markos | so you define the same function using the appropriate attribute | 17:26 |
| programmerjake | according to the gcc docs, __builtin_cpu_supports does *runtime* detection https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html#Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations | 17:26 |
| markos | in our case, we should have a regular C implementation (sffs), "vsx", "svp64", etc | 17:26 |
| markos | hm, I misread it then, you are correct, apologies, | 17:28 |
| markos | well, even better, pick a method | 17:28 |
| sadoon[m] | yep :D | 17:28 |
| markos | however, this is gcc-specific | 17:28 |
| gnucode | sadoon[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 |
| markos | sadoon[m], reg. the triplet, personally at this moment I wouldn't go there, | 17:30 |
| sadoon[m] | Yeah I agree | 17:31 |
| markos | sadoon[m], the only thing you gain is added complexity for all packages | 17:31 |
| programmerjake | imho use the icr-the-name ld.so 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 fn | 17:31 |
| markos | and in the end, we don't need another port, just a port with different defaults, which should also be backwards compatible | 17:31 |
| markos | at least on the same platform I mean | 17:32 |
| markos | obviously an svp64 can not run the old ppc64le port | 17:32 |
| markos | +system | 17:32 |
| markos | however the vsx one should be able to run the same binaries without any change | 17:32 |
| markos | but a new release should be able to run on both systems, and with proper runtime detection pick the appropriate runtime | 17:33 |
| programmerjake | one issue is the ABI for some types *requires* vsx even though those types can and should be software emulatable, e.g. __float128 | 17:35 |
| programmerjake | actually just vmx | 17:35 |
| programmerjake | so imho that's part of why we need eabi 3.0 | 17:37 |
| programmerjake | eabi 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 ld.so path | 17:38 |
| programmerjake | so old binaries run with native/emulated vsx support | 17:39 |
| markos | that's not surprising, hardware float128 was a wishlist ticket for a long time and the only way to do it was to use vmx registers | 17:40 |
| markos | vmx so that it can be used in BE as well | 17:40 |
| markos | in any case, what I mean is that we don't have to change the triplet for a future port that will support both systems | 17:43 |
| markos | I don't see how power is different in that case than arm for example | 17:43 |
| markos | they have multiple features per cpu, SVE, SVE2, ASIMD, etc, but only a single triplet for 64-bit systems aarch64-linux-gnu | 17:44 |
| markos | don't underestimate the unneeded complexity of having to add extra entries in thousands of packages | 17:45 |
| toshywoshy | the triplets should reflect the isa compliancy subsets | 17:52 |
| toshywoshy | in that way we would have the following | 17:52 |
| toshywoshy | 1. powerpc64-linux-gnu (big endian subset) | 17:52 |
| toshywoshy | powerpc64le-iinux-gnu (little endian subset) | 17:53 |
| toshywoshy | powerpc64sffs-linux-gnu (sffs subset) | 17:53 |
| toshywoshy | powerpc64sfs-linux-gnu (sfs subset) | 17:53 |
| toshywoshy | even though I think the last will be nearly never used | 17:54 |
| toshywoshy | the part I was talking about was gcc -march, which is different and we should think the same way as arm/x64 does | 17:55 |
| markos | sffs can be also either LE or BE as well right? | 17:56 |
| toshywoshy | well, yes, sffs can be BE or LE | 17:57 |
| markos | in any case, what I'm suggesting here is essentially merging powerpc64sfs-linux-gnu triplet back into powerpc64le-iinux-gnu | 17:57 |
| toshywoshy | so in fact, we should have powerpc64sffsle and powerpc64sffsbe | 17:58 |
| markos | or powerpc64-linux-gnu for BE for that matter | 17:58 |
| markos | basically changing the baseline, without changing the triplet | 17:58 |
| markos | as you said, sfs plain is probably not going to be used | 17:58 |
| toshywoshy | I am not sure we can do that, but if we do not need to create a triplet, that would be better | 17:59 |
| markos | it should definitely be possible, for existing platforms nothing would change | 17:59 |
| markos | eg. power9 | 17:59 |
| markos | for newer platforms they just wouldn't be able to run "old" distros | 17:59 |
| markos | but that would be expected anyway | 18:00 |
| toshywoshy | no but if we have a libresoc core with just sffs? | 18:00 |
| markos | sffs would be enabled, just with the same triplet | 18:00 |
| markos | let me be more specific with an example | 18:01 |
| programmerjake | imho supporting sfs is useful for embedded linux | 18:01 |
| markos | debian 12 is about to be released, this will use existing abi with VSX by default, triplet powerpc64le-iinux-gnu | 18:01 |
| markos | let's say this change is implemented in debian 14, abi changes to newer one, where VSX is now optional, and SFFS is the default | 18:02 |
| markos | same triplet | 18:02 |
| toshywoshy | that is not where the problem comes into effect | 18:03 |
| toshywoshy | if by debian14 we have different cores that can do SFFS, LE, BE | 18:03 |
| toshywoshy | how would this play out | 18:03 |
| markos | power9 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 rebuilt | 18:04 |
| markos | otoh, d14 that is installed on a libresoc system, either BE or LE, will install the same installers as power9 | 18:05 |
| toshywoshy | and would crash | 18:05 |
| markos | because SFFS will be the baseline | 18:05 |
| markos | no | 18:05 |
| markos | that's what I'm saying | 18:05 |
| markos | IF SFFS is the baseline, it will work everywhere | 18:05 |
| markos | even on power9 | 18:05 |
| markos | it will just not use VSX and underperform | 18:06 |
| toshywoshy | so the powerpc64 and powerpc64le change from the current baseline to SFFS subset | 18:06 |
| markos | yes | 18:06 |
| toshywoshy | ah, ok, and then we use the IF INCLUDE | 18:06 |
| markos | at that point VSX will be optional and glibc will just load the appropriate optimized VSX functions on Power9 with function multiversioning | 18:07 |
| markos | as Arm is currently doing for SVE2 optimized glibc functions | 18:07 |
| markos | and Intel | 18:07 |
| toshywoshy | ok, in that case, we indeed do not need an additional triplet | 18:07 |
| markos | and at the same time SVP64 will do the same on LibreSOC | 18:07 |
| toshywoshy | but then the question is whether we want to go for a baseline of SFFS or SFS | 18:07 |
| markos | that's another question | 18:08 |
| toshywoshy | I haven't actually put time into how different SFS is from SFFS | 18:08 |
| markos | if SFFS is not the baseline, then indeed SFS should be used instead | 18:08 |
| programmerjake | we do need an abi break for f128, since we need f128 softfloat support but the current abi requires vmx regardless | 18:09 |
| toshywoshy | eabi is set by opf and we can influence that, once we have a use case, so I am not too worried about that | 18:10 |
| programmerjake | if 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. debian | 18:13 |
| programmerjake | imho sfs should be like Raspbian in that you need a custom distro specifically for it, all general purpose distros should assume sffs | 18:15 |
| toshywoshy | if 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 cases | 18:17 |
| programmerjake | or, more specifically should assume the intersection of v3.0c sffs and whatever cpu first supported ppc64le (power7?) | 18:17 |
| toshywoshy | so if we think again about powerpi, I would want debian/fedora/powerel on that | 18:17 |
| programmerjake | are you expecting the powerpi to have fp? i hope yes... | 18:18 |
| toshywoshy | yes, floating point would be included | 18:19 |
| programmerjake | if yes i expect it'll support sffs intersect ppc64le | 18:19 |
| programmerjake | so no need for sfs baseline there | 18:20 |
| *** gnucode <gnucode!~joshua@user/jab> has quit IRC | 18:23 | |
| rsc | Are you referring to glibc hwcaps to avoid custom distributions? | 18:24 |
| markos | programmerjake, 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 everywhere | 18:24 |
| markos | I think the list of those is very small though | 18:24 |
| lkcl | toshywoshy, SFS is 150 instructions, specifically excluding all FP operations. SFFS is 214 and specifically includes all FP scalar operations | 18:24 |
| markos | personally I agree that sffs should be the baseline for everything | 18:24 |
| markos | and it makes sure that the port will run in all future cpus with no change | 18:25 |
| markos | and many old ones | 18:25 |
| toshywoshy | lkcl: yes, that much I remember by heart, I do not remember the details | 18:25 |
| programmerjake | imho the main issue we'll run into is binary libraries with the old abi that people try to link stuff in the new abi to | 18:25 |
| markos | we can easily disable that | 18:26 |
| markos | it's not like power is full with old legacy software that one would want to use on a newer system, this is not x86 | 18:27 |
| markos | I would tackle those cases when/if they come | 18:27 |
| lkcl | programmerjake, a new ABI has already been very specifically vetoed by paul mackerras. | 18:29 |
| lkcl | proposals 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 |
| lkcl | you have been told this already. i am reminding you of it for the second time | 18:30 |
| programmerjake | but debian/etc. doesn't use eabi 1.5 | 18:31 |
| markos | no they don't | 18:31 |
| markos | we 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 same | 18:32 |
| programmerjake | well, that's a breaking change so that becomes eabi 3.0 | 18:32 |
| programmerjake | unless the eabi doesn't follow semver | 18:33 |
| toshywoshy | well, 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 defined | 18:34 |
| toshywoshy | breaking changes will make the major number increase | 18:35 |
| programmerjake | so, since it's breaking, imho we fix f128 abi to not require vsx while we have the chance | 18:35 |
| programmerjake | f128 isn't in eabi 1.5 | 18:35 |
| programmerjake | so 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 |
| markos | there is only one solution really | 18:42 |
| markos | eabi 3.0 w/o vsx/vmx | 18:43 |
| markos | or whatever version number that's going to be | 18:43 |
| programmerjake | minimal vsx subset might actually work | 18:43 |
| markos | only if it's an emulated one | 18:43 |
| markos | tbh I wouldn't even bother with that | 18:44 |
| programmerjake | minimal vsx subset *in hw* | 18:44 |
| markos | I honestly don't see a problem | 18:45 |
| markos | the apps affected will be minimal | 18:45 |
| markos | and the problem will only manifest on cpus that do NOT have VSX and try to use OLD apps that use float128 instructions | 18:45 |
| markos | all new apps would have the new abi | 18:45 |
| markos | s/have/be rebuilt/ | 18:45 |
| programmerjake | not even float128 insns, anything using softfloat f128 at all | 18:46 |
| markos | even those | 18:47 |
| markos | the problem is easily fixable in our case, because we control both hardware and software | 18:47 |
| markos | the chances of someone running an old *binary* app that uses float128 on a libresoc are probably close to zero | 18:48 |
| markos | most likely it will be a distro app and we will just recompile with the new abi, problem solved | 18:48 |
| markos | we will have to recompile the world anyway | 18:49 |
| programmerjake | would 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 accidental | 18:50 |
| markos | yes ofc, changing the abi implies fixing the compilers as well :) | 18:50 |
| programmerjake | llvm appears to default to passing f128 in a pair of int regs when -mno-altivec is given: https://llvm.godbolt.org/z/4aszdfrbb | 18:56 |
| markos | so all good then | 18:57 |
| programmerjake | no, afaict it's completely accidental and may not be consistent, we'll need to ensure it matches whatever the eabi 3.0 says | 18:59 |
| markos | I don't think it's accidental, if -mno-altivec is used then there are no VMX registers available and the compiler *has* to use GPRs | 19:00 |
| markos | and I bet softfloat128 code is inserted for the operations | 19:00 |
| programmerjake | i'd expect llvm just does whatever random thing was easiest at the time, with no thought for abi compatibility at all. | 19:01 |
| programmerjake | it does call softfloat functions, but afaict those functions take arguments and return values in vmx regs so there's an abi mismatch | 19:02 |
| markos | I 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 altivec | 19:02 |
| programmerjake | but those use the old eabi, -mno-altivec still uses eabi 2.0 here which says "use vmx regs" | 19:03 |
| programmerjake | the old eabi says nothing at all about f128, i checked | 19:03 |
| markos | the mechanism of passing values through the vmx registers I meant, even with -mno-altivec, this is not a new thing | 19:05 |
| markos | in any case, if llvm does this, it's quite likely that gcc will also do something similar, if not then it's definitely a bug | 19:05 |
| programmerjake | afaict previously vmx regs were only used for vmx types, all other types used fprs/gprs/stack | 19:06 |
| programmerjake | afaict gcc just disables f128 type support completely | 19:06 |
| markos | well, float128 is special and ibm-only | 19:06 |
| markos | in hardware I mean | 19:06 |
| markos | everyone else does it in software | 19:07 |
| programmerjake | float128 is supported in the ABI on many other arches | 19:07 |
| markos | as a type yes, but it's all emulated | 19:07 |
| markos | and passed through GPRS | 19:07 |
| markos | or stack | 19:07 |
| programmerjake | no, on x86-64 iirc it's passed in sse regs | 19:08 |
| markos | afaik there is no other platform with hardware float128, integer 128-bit yes | 19:08 |
| markos | because x86-64 assumes SSE2 iirc | 19:08 |
| programmerjake | uuh, zseries and riscv have hw f128 iirc | 19:08 |
| markos | ok, the first is IBM and the other is a brand new arch with a fluid ABI, not much is set in stone yet | 19:09 |
| markos | in any case | 19:09 |
| markos | my point is that I don't think it's an accident | 19:09 |
| markos | I think it's doing the right thing and in that case, this is a non-issue then | 19:10 |
| markos | because 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 working | 19:11 |
| programmerjake | k, well gcc is definitely not doing what we want, no f128 whatsoever | 19:11 |
| markos | ok, good | 19:12 |
| markos | it is actually doing exactly what we want | 19:12 |
| markos | it does not cause a problem | 19:13 |
| programmerjake | except sw expects to have the __ieee128 type and it isn't there so the sw fails to compile, iirc sadoon was running into this issue | 19:14 |
| programmerjake | so it is a problem | 19:14 |
| markos | if the software fails to compile that's not our problem at all | 19:15 |
| markos | the problem is with compiled software with the wrong assumptions and using VSX registers that would eventually run in a CPU without VSX | 19:16 |
| markos | this is a compiler problem, not an EABI problem, or actually it's the problem of the software itself | 19:16 |
| markos | and most likely easily fixable | 19:17 |
| programmerjake | i 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 insns | 19:17 |
| markos | wchar_t type is NOT arch specific | 19:17 |
| markos | float128 is | 19:17 |
| programmerjake | the sw wants __float128 and doesn't care if it's sw emulated | 19:17 |
| programmerjake | and iirc __float128 is available on basically every arch in gcc thanks to libquadmath | 19: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 available | 19:18 |
| markos | exactly | 19:19 |
| markos | libquadmath | 19:19 |
| markos | ie software | 19:19 |
| programmerjake | but you're missing my point, gcc provides that sw emulation through the __float128 type | 19:20 |
| markos | but it's a gcc-ism | 19:20 |
| markos | if it's sw-emulated then it's definitely NOT using the VMX registers | 19:20 |
| programmerjake | true, but any decent compiler on linux supports those gcc-isms | 19:20 |
| markos | so there is no problem | 19:21 |
| programmerjake | it *is* using vmx because that's what the abi says regardless of if you're using the f128 insns or not | 19:21 |
| markos | you just said it cannot even use the f128 types if -mno-altivec is passed | 19:22 |
| programmerjake | yes, because gcc doesn't really support -mno-altivec on eabi 2.0 | 19:22 |
| programmerjake | no f128 types is a symptom of no gcc support | 19:23 |
| markos | ok, I think we're talking passed each other, we care only about -mno-altivec here, we don't care what the current ABI does | 19:23 |
| markos | if 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-altivec | 19:24 |
| markos | or use clang/llvm which seems to just use software float128 | 19:24 |
| programmerjake | what i care about is gcc regaining support for f128 with -mno-altivec and *being 100% compatible* with clang | 19:25 |
| markos | no, we don't care about this at this point | 19:25 |
| markos | it really is a very very small issue | 19:25 |
| markos | if 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 compilers | 19:26 |
| programmerjake | well, i think we've got our points across and further arguing is pointless | 19:26 |
| markos | then either they don't care, or there is a good reason for ti | 19:26 |
| markos | but 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 scope | 19:28 |
| programmerjake | imho they could care less about -mno-altivec on eabi 2.0 since it's a logical contradiction | 19:28 |
| programmerjake | except maybe for the linux kernel abi where all fp regs are off limits | 19:29 |
| programmerjake | well ttyl | 19:30 |
| *** octavius <octavius!~octavius@92.40.169.69.threembb.co.uk> has joined #libre-soc | 19:32 | |
| octavius | lkcl, saw your new bug 1013. What about ls001/002? | 19:33 |
| sadoon[m] | Unrelated, but | 19:40 |
| * sadoon[m] is tired trying to build qtwebengine for G5 | 19:40 | |
| sadoon[m] | If only KDE was not so reliant on it :( | 19:41 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 19:58 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 19:59 | |
| *** octavius <octavius!~octavius@92.40.169.69.threembb.co.uk> has quit IRC | 20:25 | |
| *** octavius <octavius!~octavius@92.40.169.71.threembb.co.uk> has joined #libre-soc | 20:45 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 21:41 | |
| *** octavius <octavius!~octavius@92.40.169.71.threembb.co.uk> has quit IRC | 22:07 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 23:20 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 23:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 23:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 23:54 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!