Thursday, 2023-03-02

*** ghostmansd[m] <ghostmansd[m]!> has quit IRC01:14
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc01: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]disabling either vsx or altivec gives the error02:28
sadoon[m] ignore the first error regarding vsx and altivec02:29
sadoon[m]the correct fix seems to -mlong-double-64, wow that took almost a full day lol02:42
programmerjakeimho that may not be what we want in the long run, lots of code assumes long double isn't just double in disguise02:50
programmerjakebut it'll probably work for now02:51
sadoon[m]do you think we should basically do hard 64-bit float and soft 128-bit float?02:51
sadoon[m]There may be a way to do that with the options we have02:52
programmerjakeor at least soft double-double for long double02:52
sadoon[m]I'll look into it now as the packages are being rebuilt02:53
programmerjakei 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 regs02:54
programmerjakegcc apparently took the easy way out and disabled f128 for -mno-altivec02:54
sadoon[m]That is a problem for any software that used f128..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 well02:56
programmerjakeno, because we can use the exact same patch since libre-soc also doesn't have f128 hw02:56
sadoon[m]But libre-soc can do f128 in SVP64 can't it?02:57
programmerjakeor 128-bit regs02:57
programmerjakeno, only f64/f32/f16/bf1602:57
sadoon[m]I see02:57
programmerjakea future extension would add f128 hw support and probably 128-bit regs, but that's not planned for quite a while02: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/llvm02:59
programmerjakeprogrammerjake: maybe never02:59
sadoon[m]Rebuilding gentoo now to see how it behaves02:59
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC03: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-soc03: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 endian03:44
sadoon[m]Alright I'll be heading off to work, afk03: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]!> has quit IRC05:49
*** Ritish <Ritish!~Ritish@> has joined #libre-soc06:03
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc06:11
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:25
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:30
*** Ritish <Ritish!~Ritish@> has quit IRC07:50
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:42
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC08:48
*** Ritish <Ritish!~Ritish@> has joined #libre-soc08:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc08:52
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc09:29
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC09:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc09:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:02
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10:05
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10:27
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC11:07
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc11:08
*** Ritish <Ritish!~Ritish@> has quit IRC11:20
lkclthe 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
lkclthe transition from EABI 1.5 to EABI 1.9 was where all hell broke loose11:25
lkclyou need 128-bit pipelines containing a whopping 256-bit internal temporary registers/latches to perform 128-bit calculations.11:27
lkcland you need 128-bit registers to store the 128-bit results11:27
lkcli 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
lkclit 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 :D11:33
lkclof course, that doesn't necessarily mean that e.g. the libc6 developers (or others) did not put direct assembler into the darn code, sigh11:44
lkclbut it's a great sign11:44
sadoon[m]that's where using qemu and emulating an e6500 would be somewhat helpful11:45
sadoon[m]although then we might need to temporarily target power7 or whatever that was11:45
lkclblech :)11:49
lkclwell.. 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
lkclif so, getting a full log of all instructions would allow grep to seek out the culprits11:49
sadoon[m]It might be.. then we'd just use qemu-user I guess11:49
lkcltoshywoshy, what were the options you used to run ppc64le-sffs, on qemu?11:50
lkclthen you'd just get an illegal exception thrown11:50
sadoon[m]Even better11:50
lkclwhich, hmmm, might be picked up by gdb somehow...11:50
lkclor... you get the idea11:51
lkclneed to make sure this conversation's cross-linked into the bugreport, 1sec...11:51
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 hopefully11:54
sadoon[m]I need to touch grass, might do it in the literal sense11:54
sadoon[m]bye :P11:54
lkclsadoon[m], i'm a known-tree-hugger :)11:57
lkcli totally understand11:57
sadoon[m]Actually I just had a crazy idea I wanted to share before leaving11: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 -mcpu12: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
lkclthat's what the triplet is for.12:00
lkclbut yes.12:00
lkcl-mcpu=sffs3.0 or something12:00
sadoon[m]So currently -mcpu=power9 gives you vsx, altivec, float128 etc12:01
sadoon[m]There would be a -mcpu=isa_3.0 or something to that effect12:01
lkclbecause remember there is microwatt as well12:01
lkclso it cannot be "-mlibresoc"12:01
sadoon[m]Obviously yeah12:01
lkclor it could (gratuitous-self-promote, gratuitous-self-promote...)12:01
sadoon[m]I could literally do this in one sitting (I hope)12:01
sadoon[m]Heh, -mlibresoc for when it hopefully includes svp64 optimizations yeah?12:02
sadoon[m]Sorry, -mcpu=libresoc12: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 this12:04
sadoon[m]Bye :)12:04
markosthis is where something like -march=armv8 is convenient, without having to worry about actual cpu12:32
markosso, instead of -mcpu=isa_3.0, which does not seem nice, we should also have the -march flag, with -march=isa3.0 or sth similar12:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC12:33
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc12:33
sadoon[m]-march isn't supported on powerpc unfortunately12:39
markosyes, though that doesn't mean it cannot be added in the future for exactly the same purposes12:57
markosin fact we could add it ourselves as part of a task12:59
markosie, as part of compiler support :)12:59
*** ghostmansd <ghostmansd!> has quit IRC14:19
sadoon[m]Is there a specific reason to do so though?14:52
lkcldebian 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
lkclbut we do want to end up doing the same thing as intel's "levels"14:53
lkclwhere runtime detection of "hardware capabilities" actually redirects a function to a completely different version specifically optimised for that hardware14:54
lkclthe *base* of that architecture would be "-march=sffs_isa_3.0" and the variants would then add on top of that14:55
toshywoshyWell I used -march=power9 -mno-power8-fusion -mpower8-vector -mcrypto -maltivec -mvrsave -mvsx -mfloat128 -mfloat128-hardwar14:55
toshywoshysorry, 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-hardware14:56
toshywoshyI 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 included14:57
toshywoshysimilar to what intel/amd and arm already do, so it should be very easy to maintain from gcc14:58
toshywoshyI do not have the qemu spec at hand, but I need to post all of these details somewhere central14:59
markosfor comparison this is arm (ampere): -march=armv8.2-a+crypto+fp16+rcpc+dotprod15:03
markoswe could do something similar15:03
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:17
markosso 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 base15:38
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15:47
markossorry, just realized toshywoshy said exactly the same thing :)16:22
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:45
programmerjakeimho we need a new triple because lots of code doesn't allow passing additional compiler flags (e.g. poorly designed custom Makefile)17:00
programmerjakeso we need the compiler to default to sffs without any flags needed whatsoever17:00
toshywoshyyes, and if you use -march=power9 it expands to -march=powerisa30+vsx+altivec+crypto, similar to -march=power10 to then have mma enabled17:02
toshywoshyas 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 ecosystem17:03
programmerjakeimho 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 features17:11
programmerjakeor 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 simpler17:14
programmerjakepower10 would definitely benefit from that too, so ibm may be more inclined to do that17:15
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:17
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC17:42
markostoshywoshy, I must have missed something, isn't sffs basically the baseline? and everything else sits on top?17:47
markosor is there an even more limited baseline?17:47
toshywoshythe powerisa provides 4 compliancy sets : sfs, sffs, le, be17:48
toshywoshywhile the sfs is very limited, I do not think that we will have a direct interest in this subset17:48
toshywoshyhowever I think having sffs, le, be seperate would be good17:49
markosif sfs as too limited to be useful why include it at all?17:49
toshywoshyso that means having ppc64sffs, ppc64le/ppc64el, ppc6417:49
markosaren't le/be always implied by default in power ISA?17:50
markossupport for those I mean17:50
markosat least outside the vector unit17:50
markosor you mean we would also make those optional?17:51
markosin 3.217:51
toshywoshynot sure what you mean by implied, but the levels are sequential17:51
toshywoshymeaning, le always has sffs and sfs, be has le, sffs, sfs17:51
markoswell, 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 capable17:52
toshywoshyso an le implementation does not need to have be instructions17:52
toshywoshyyes, all IBM CPU's implement by default BE, and thus have all lower subsets included17:53
toshywoshy... till date ...17:53
markosis there *any* vendor that is interested in just a plain sfs implementation?17:54
markosanyway, I'm just nitpicking, I was just suggesting to call sffs the baseline17:55
markosthis way we can avoid a new triplet, and duplicate distro ports17:55
markoswe "only" would have to make the software provide runtime detection of features such as VSX/altivec/etc17:56
markosit's hard, but definitely doable17:56
markosI'd go as far to say that it's easier than providing a full port17:56
markosthe changes to the software (eg. glibc) has to happen anyway17:57
markosbut you don't have to submit hundreds/thousands of patches to packages with new triplets to scripts17:58
markosI've had to do that in the past, it's certainly doable, but it's no fun at all17:58
programmerjakeif 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 simultaneously18:07
programmerjakeaka powerpc64sffs implies eabi 3.018:07
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:09
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC20:07
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc20:11
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc21:09

Generated by 2.17.1 by Marius Gedminas - find it at!