| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 01:14 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 01:44 | |
| sadoon[m] | Bingo! The problem starts to be introduced when including <string> in a c++ program, the offending file is "/usr/lib/gcc/powerpc64le-unknown-linux-gnu/12/include/g++-v12/ext/numeric_traits.h" | 02:15 |
|---|---|---|
| sadoon[m] | https://pastebin.com/wTpZxFrY | 02:16 |
| sadoon[m] | disabling either vsx or altivec gives the error | 02:28 |
| sadoon[m] | https://pastebin.com/vybnMZfc ignore the first error regarding vsx and altivec | 02:29 |
| sadoon[m] | the correct fix seems to -mlong-double-64, wow that took almost a full day lol | 02:42 |
| programmerjake | imho that may not be what we want in the long run, lots of code assumes long double isn't just double in disguise | 02:50 |
| programmerjake | but it'll probably work for now | 02:51 |
| sadoon[m] | do you think we should basically do hard 64-bit float and soft 128-bit float? | 02:51 |
| programmerjake | yes | 02:52 |
| sadoon[m] | There may be a way to do that with the options we have | 02:52 |
| programmerjake | or at least soft double-double for long double | 02:52 |
| sadoon[m] | I'll look into it now as the packages are being rebuilt | 02:53 |
| programmerjake | i think the f128 ABI requires altivec registers, so sffs will need a different ABI (same thing for floats in general for sfs) | 02:53 |
| sadoon[m] | You're right it does require altivec regs | 02:54 |
| programmerjake | gcc apparently took the easy way out and disabled f128 for -mno-altivec | 02:54 |
| sadoon[m] | That is a problem for any software that used f128.. | 02:55 |
| sadoon[m] | uses* | 02:55 |
| sadoon[m] | But it'll be wasted effort to patch gcc/llvm to support soft 128 when we have svp64 incoming and need to patch for that as well | 02:56 |
| sadoon[m] | right? | 02:56 |
| programmerjake | no, because we can use the exact same patch since libre-soc also doesn't have f128 hw | 02:56 |
| sadoon[m] | But libre-soc can do f128 in SVP64 can't it? | 02:57 |
| programmerjake | or 128-bit regs | 02:57 |
| programmerjake | no, only f64/f32/f16/bf16 | 02:57 |
| sadoon[m] | I see | 02:57 |
| programmerjake | a future extension would add f128 hw support and probably 128-bit regs, but that's not planned for quite a while | 02:58 |
| sadoon[m] | Alright then, I'll wait for lkcl to see and share what he thinks, I guess like you said this hack will work for now until we do patch gcc/llvm | 02:59 |
| programmerjake | programmerjake: maybe never | 02:59 |
| sadoon[m] | Rebuilding gentoo now to see how it behaves | 02:59 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:00 | |
| sadoon[m] | btw the current flags are "-mcpu=power9 -mno-altivec -mno-vsx -mno-crypto -mno-htm -mlong-double-64" | 03:01 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 03:01 | |
| sadoon[m] | Wouldn't you know, 97 packages of 272 so far, no failures at all. | 03:28 |
| sadoon[m] | Also worth noting: qemu supports the e6500 which is the closest to sffs we'll get as long as we use little endian since it has no altivec in little endian | 03:44 |
| sadoon[m] | afaik | 03:44 |
| sadoon[m] | Alright I'll be heading off to work, afk | 03:45 |
| Ryuno-KiAndrJaen | <sadoon[m]> "Is forgejo's UI any different..." <- We're fixing accessibility issues if upstream doesn't want to 😇 | 05:39 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 05:49 | |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has joined #libre-soc | 06:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 06:11 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:25 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:30 | |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has quit IRC | 07:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:42 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 08:48 | |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has joined #libre-soc | 08:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 08:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 09:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 09:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has joined #libre-soc | 09:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has quit IRC | 10:02 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has joined #libre-soc | 10:05 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has quit IRC | 10:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has joined #libre-soc | 10:27 | |
| sadoon[m] | Cool | 10:28 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 11:07 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 11:08 | |
| *** Ritish <Ritish!~Ritish@60.243.42.218> has quit IRC | 11:20 | |
| lkcl | the EABI we'll need to use is EABI 1.5. i have a copy kicking around somewhere. we cannot and must not invent our own EABI. | 11:25 |
| lkcl | the transition from EABI 1.5 to EABI 1.9 was where all hell broke loose | 11:25 |
| lkcl | you need 128-bit pipelines containing a whopping 256-bit internal temporary registers/latches to perform 128-bit calculations. | 11:27 |
| lkcl | and you need 128-bit registers to store the 128-bit results | 11:27 |
| lkcl | i have said multiple times that such is going way too far for a first ASIC, and that's just not going to change. | 11:27 |
| lkcl | it would result in unrealistic goals that would jeapordise the project's commercial viability. | 11:28 |
| sadoon[m] | That's good news for me then :) | 11:33 |
| sadoon[m] | I've had 0 build failures so far with these options btw, gentoo base packages built successfully :D | 11:33 |
| lkcl | aaawwesome | 11:43 |
| lkcl | of course, that doesn't necessarily mean that e.g. the libc6 developers (or others) did not put direct assembler into the darn code, sigh | 11:44 |
| lkcl | but it's a great sign | 11:44 |
| sadoon[m] | that's where using qemu and emulating an e6500 would be somewhat helpful | 11:45 |
| sadoon[m] | although then we might need to temporarily target power7 or whatever that was | 11:45 |
| lkcl | blech :) | 11:49 |
| lkcl | well.. is it possible to do full instruction-tracing in qemu? | 11:49 |
| sadoon[m] | I know, I know, but then we can guarantee to altivec or vsx (I think?) | 11:49 |
| lkcl | if so, getting a full log of all instructions would allow grep to seek out the culprits | 11:49 |
| sadoon[m] | It might be.. then we'd just use qemu-user I guess | 11:49 |
| lkcl | toshywoshy, what were the options you used to run ppc64le-sffs, on qemu? | 11:50 |
| lkcl | then you'd just get an illegal exception thrown | 11:50 |
| sadoon[m] | Even better | 11:50 |
| lkcl | which, hmmm, might be picked up by gdb somehow... | 11:50 |
| lkcl | or... you get the idea | 11:51 |
| lkcl | need to make sure this conversation's cross-linked into the bugreport, 1sec... | 11:51 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=961 | 11:51 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=999 | 11:51 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2023-03-02.log.html#t2023-03-02T02:15:14 | 11:52 |
| lkcl | done | 11:52 |
| sadoon[m] | Alright, I'll call this good progress then :) | 11:53 |
| sadoon[m] | Won't be available for the rest of the day though, next I'll work on finishing up a full system hopefully | 11:54 |
| sadoon[m] | I need to touch grass, might do it in the literal sense | 11:54 |
| sadoon[m] | bye :P | 11:54 |
| lkcl | sadoon[m], i'm a known-tree-hugger :) | 11:57 |
| lkcl | i totally understand | 11:57 |
| sadoon[m] | Actually I just had a crazy idea I wanted to share before leaving | 11:59 |
| sadoon[m] | Do we *need* a new gcc/llvm target? | 12:00 |
| sadoon[m] | I mean the current way to do things is simply by -mcpu | 12:00 |
| sadoon[m] | We could just implement sffs as an -mcpu, it would save us a *ton* of work and achieve the same purpose wouldn't it? | 12:00 |
| lkcl | that's what the triplet is for. | 12:00 |
| lkcl | but yes. | 12:00 |
| lkcl | -mcpu=sffs3.0 or something | 12:00 |
| sadoon[m] | So currently -mcpu=power9 gives you vsx, altivec, float128 etc | 12:01 |
| sadoon[m] | There would be a -mcpu=isa_3.0 or something to that effect | 12:01 |
| lkcl | because remember there is microwatt as well | 12:01 |
| lkcl | so it cannot be "-mlibresoc" | 12:01 |
| sadoon[m] | Obviously yeah | 12:01 |
| lkcl | or it could (gratuitous-self-promote, gratuitous-self-promote...) | 12:01 |
| sadoon[m] | I could literally do this in one sitting (I hope) | 12:01 |
| lkcl | yaay | 12:01 |
| sadoon[m] | Heh, -mlibresoc for when it hopefully includes svp64 optimizations yeah? | 12:02 |
| sadoon[m] | Sorry, -mcpu=libresoc | 12:02 |
| sadoon[m] | Let's discuss this -mcpu thing next week during the meeting, until then I'll keep building packages and watching what fails, though I now have a good feeling about this | 12:04 |
| sadoon[m] | Bye :) | 12:04 |
| markos | this is where something like -march=armv8 is convenient, without having to worry about actual cpu | 12:32 |
| markos | so, instead of -mcpu=isa_3.0, which does not seem nice, we should also have the -march flag, with -march=isa3.0 or sth similar | 12:33 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.106> has quit IRC | 12:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 12:33 | |
| sadoon[m] | -march isn't supported on powerpc unfortunately | 12:39 |
| markos | yes, though that doesn't mean it cannot be added in the future for exactly the same purposes | 12:57 |
| markos | in fact we could add it ourselves as part of a task | 12:59 |
| markos | ie, as part of compiler support :) | 12:59 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:19 | |
| sadoon[m] | Is there a specific reason to do so though? | 14:52 |
| lkcl | debian will flatly refuse to accept an upstream distro unless there is a compiler "/usr/bin/gcc" which supports precisely and exactly the native distro target. | 14:53 |
| lkcl | but we do want to end up doing the same thing as intel's "levels" | 14:53 |
| lkcl | where runtime detection of "hardware capabilities" actually redirects a function to a completely different version specifically optimised for that hardware | 14:54 |
| lkcl | the *base* of that architecture would be "-march=sffs_isa_3.0" and the variants would then add on top of that | 14:55 |
| lkcl | svp64 | 14:55 |
| lkcl | vsx | 14:55 |
| lkcl | {insert_future_vector_system_by_another_third_party} | 14:55 |
| toshywoshy | Well I used -march=power9 -mno-power8-fusion -mpower8-vector -mcrypto -maltivec -mvrsave -mvsx -mfloat128 -mfloat128-hardwar | 14:55 |
| toshywoshy | sorry, that is the wrong line copied, -march=power9 -mno-power8-fusion -mno-power8-vector -mno-crypto -mno-altivec -mno-vrsave -mno-vsx -mno-float128 -mno-float128-hardware | 14:56 |
| toshywoshy | I have been advocating for having the march changed to powerisa30 for power9 and powerisa31 for power10 and then have the next gen of ibm power linked to the isa with default options already included | 14:57 |
| toshywoshy | similar to what intel/amd and arm already do, so it should be very easy to maintain from gcc | 14:58 |
| toshywoshy | I do not have the qemu spec at hand, but I need to post all of these details somewhere central | 14:59 |
| markos | for comparison this is arm (ampere): -march=armv8.2-a+crypto+fp16+rcpc+dotprod | 15:03 |
| markos | we could do something similar | 15:03 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:17 | |
| markos | so for sffs, it should be -march=powerisa30 plain, powerisa30+vsx+altivec+crypto plus a few others would give you Power8/Power9, and powerisa31+svp64 would just give you libresoc (or powerisa32), sffs should not be needed as it should be considered the base | 15:38 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:47 | |
| markos | sorry, just realized toshywoshy said exactly the same thing :) | 16:22 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 16:45 | |
| programmerjake | imho we need a new triple because lots of code doesn't allow passing additional compiler flags (e.g. poorly designed custom Makefile) | 17:00 |
| programmerjake | so we need the compiler to default to sffs without any flags needed whatsoever | 17:00 |
| toshywoshy | yes, and if you use -march=power9 it expands to -march=powerisa30+vsx+altivec+crypto, similar to -march=power10 to then have mma enabled | 17:02 |
| toshywoshy | as for the sffs, I think we should have that, even if svp64 comes, it makes sense for embedded of smaller devices, so in the future, we can have that in the ecosystem | 17:03 |
| programmerjake | imho we'll want a eabi v3.0 which, like opencl 3.0, makes lots of new features optional again so everyone can implement it, just using eabi 1.5 is imho a bad idea in the long run because we'd effectively be discarding eabi 2.0 improvements that make the ABI nicer to use without needing new cpu features | 17:11 |
| programmerjake | or maybe we want eabi 3.0 to be based on powerisa v3.1 sffs so we don't need all the extra ABI code catering to not having 34-bit immediates and pc-relative addressing, imho that way the ABI could be a lot simpler | 17:14 |
| programmerjake | power10 would definitely benefit from that too, so ibm may be more inclined to do that | 17:15 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:17 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:42 | |
| markos | toshywoshy, I must have missed something, isn't sffs basically the baseline? and everything else sits on top? | 17:47 |
| markos | or is there an even more limited baseline? | 17:47 |
| toshywoshy | the powerisa provides 4 compliancy sets : sfs, sffs, le, be | 17:48 |
| markos | ah | 17:48 |
| toshywoshy | while the sfs is very limited, I do not think that we will have a direct interest in this subset | 17:48 |
| toshywoshy | however I think having sffs, le, be seperate would be good | 17:49 |
| markos | if sfs as too limited to be useful why include it at all? | 17:49 |
| toshywoshy | so that means having ppc64sffs, ppc64le/ppc64el, ppc64 | 17:49 |
| markos | aren't le/be always implied by default in power ISA? | 17:50 |
| markos | support for those I mean | 17:50 |
| markos | at least outside the vector unit | 17:50 |
| markos | or you mean we would also make those optional? | 17:51 |
| markos | in 3.2 | 17:51 |
| toshywoshy | not sure what you mean by implied, but the levels are sequential | 17:51 |
| toshywoshy | meaning, le always has sffs and sfs, be has le, sffs, sfs | 17:51 |
| markos | well, apart from the very early cpus, I'm not really aware of any recent Power CPU (or even PowerPC) that has not been both LE and BE capable | 17:52 |
| toshywoshy | so an le implementation does not need to have be instructions | 17:52 |
| toshywoshy | yes, all IBM CPU's implement by default BE, and thus have all lower subsets included | 17:53 |
| toshywoshy | ... till date ... | 17:53 |
| markos | is there *any* vendor that is interested in just a plain sfs implementation? | 17:54 |
| markos | anyway, I'm just nitpicking, I was just suggesting to call sffs the baseline | 17:55 |
| markos | this way we can avoid a new triplet, and duplicate distro ports | 17:55 |
| markos | we "only" would have to make the software provide runtime detection of features such as VSX/altivec/etc | 17:56 |
| markos | it's hard, but definitely doable | 17:56 |
| markos | I'd go as far to say that it's easier than providing a full port | 17:56 |
| markos | the changes to the software (eg. glibc) has to happen anyway | 17:57 |
| markos | but you don't have to submit hundreds/thousands of patches to packages with new triplets to configure.ac/etc scripts | 17:58 |
| markos | I've had to do that in the past, it's certainly doable, but it's no fun at all | 17:58 |
| programmerjake | if we do have eabi 3.0, imho we will want to do it before marking powerpc64sffs as stable upstream, that way we don't have to transition everyone twice, everyone would transition to both simultaneously | 18:07 |
| programmerjake | aka powerpc64sffs implies eabi 3.0 | 18:07 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:09 | |
| markos | yup | 19:40 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:11 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 21:09 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!