| lkcl | lxo: it's rather unfortunate that david's not quite fully grasping the significant of SV. | 19:50 |
|---|---|---|
| lkcl | what would you suggest here? | 19:50 |
| lxo | maybe that it shouldn't have been me making the introduction :-( | 20:37 |
| lxo | there's some history of hostility towards rms and myself there | 20:38 |
| lxo | hopefully that's not the reason for this reaction, though | 20:38 |
| lxo | maybe it's just about the complexity this will add to a port that already has a lot of it | 20:41 |
| lxo | maybe he's just dismissive for not realizing how far we are into getting buy-in from the openpower foundation | 20:42 |
| lxo | or maybe we aren't getting it and we don't know it but he does | 20:43 |
| *** ed97 is now known as Mopar_ed | 20:59 | |
| lkcl | lxo: the assessment "it's like the NXP SPE SIMD extension" has me deeply concerned | 21:27 |
| lkcl | if there are people inside IBM discussing it and they think it's a variant of SSE2 that's simply alarming | 21:28 |
| mopar426_ed | hi guys! I finally got some free time again, when I try the make install for soc I get: | 21:30 |
| mopar426_ed | python3 setup.py develop --user # yes, develop, not install | 21:30 |
| mopar426_ed | usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] | 21:30 |
| mopar426_ed | or: setup.py --help [cmd1 cmd2 ...] | 21:30 |
| mopar426_ed | or: setup.py --help-commands | 21:30 |
| mopar426_ed | or: setup.py cmd --help | 21:30 |
| mopar426_ed | error: option --user not recognized | 21:30 |
| mopar426_ed | make: *** [Makefile:17: develop] Error 1 | 21:31 |
| mopar426_ed | has any of you run into this? | 21:31 |
| lkcl | mopar426_ed, hi. do stick around if you can with the chat :) | 21:31 |
| lkcl | i've never used "--user" | 21:31 |
| lkcl | i've only ever done straight "python3 setup.py develop" under root | 21:31 |
| lkcl | can you do "python3 --version" ? what does it say? | 21:31 |
| mopar426_ed | I just removed --user from the Makefile and it is going through | 21:32 |
| lkcl | excellent | 21:32 |
| lkcl | Makefile? moo? | 21:32 |
| * lkcl goes to check | 21:32 | |
| lkcl | ah yes i see | 21:32 |
| * lkcl removing that | 21:32 | |
| lkcl | mopar426_ed: thanks for spotting that | 21:33 |
| lkcl | btw do make sure you do the installs in the exact order | 21:33 |
| lkcl | listed in HDL_workflow | 21:33 |
| lkcl | otherwise what will happen is that the extremely annoying pip3 will go, "oh you don't have x y z dependency. JUST let me go get that for you and f*** up your system" | 21:33 |
| lkcl | :) | 21:34 |
| mopar426_ed | haven't seen that page yet, I'm checking from the "5.1 quick peek at the code" | 21:34 |
| lkcl | ok 1 sec | 21:34 |
| lkcl | https://libre-soc.org/HDL_workflow/ | 21:34 |
| mopar426_ed | thanks, I'll read through | 21:34 |
| lkcl | the last thing you want is for some dependency to drag in a downloaded (out-of-date) version of nmigen-0.1 or something | 21:34 |
| lkcl | you _can_ use these automated scripts if you want | 21:35 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=tree;h=cec0baf05763221460ce3781dada9d4af51c99da;hb=cec0baf05763221460ce3781dada9d4af51c99da | 21:35 |
| lkcl | this one gets every-dependency-you-need-in-one-hit | 21:35 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD | 21:35 |
| mopar426_ed | awesome, I'll check those. that should save me some time. | 21:36 |
| lkcl | this one does *some* of the python-based stuff | 21:36 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-dev-repos;hb=HEAD | 21:36 |
| lkcl | and we really should do one for getting gdb and powerpc64-gnu-linux-gcc as well | 21:36 |
| lkcl | gdb you _have_ to get from source, because nobody does a cross-compiler debian package of binutils+gdb | 21:37 |
| lkcl | hmm i'll write one of those now | 21:40 |
| lkcl | mopar426_ed: are you using debian buster by chance? | 21:41 |
| mopar426_ed | yes, I got the gdb tarball and will compile it for powerpc | 21:42 |
| mopar426_ed | yes, I use buster | 21:42 |
| lkcl | ok great. that's... gcc-8-powerpc64-linux-gnu, right? | 21:43 |
| lkcl | or does it have gcc-9 ? (i use debian/testing so i can't tell) | 21:43 |
| mopar426_ed | no buster only has 8 | 21:44 |
| lkcl | okaay then i'll put that into the script. thank you | 21:45 |
| mopar426_ed | no problem | 21:46 |
| * lkcl just testing it | 21:48 | |
| lxo | lkcl, I think his labeling it as SPE-like has nothing to do with the technical details, but rather with the approach of "forking" the powerpc architecture | 21:50 |
| lxo | which is still very unfortunate, because SPE turned out to be an evolutionary dead end, precisely because its extensions did not get integrated | 21:51 |
| lkcl | true... yet it stems from him not having understood that we've spent considerable time *not* designing something that "rips bits out of OpenPOWER and adds some totally different stuff to it" | 21:52 |
| lkcl | to the point where i have very specifically resisted all and every effort to do *anything* different from the v3.0B ISA *specifically* so that if challenged precisely in this way we could say "no that is *not* what SV does, it does *NOT* replace, change, alter, rip out, or otherwise do ANYTHING to the OpenPOWER v3.0B scalar ISA in any way, shape or form" | 21:55 |
| lxo | well... we are departing from altivec and vsx | 21:56 |
| lxo | even if we don't regard it as core openpower, I gather he doesn't draw the line at the same place | 21:57 |
| lkcl | not departing: just... not implementing. | 21:58 |
| lkcl | now, *other vendors* may choose to make a different call there. | 21:58 |
| lkcl | the decision *by us* to not implement VSX (because frankly it is insane and would completely jeapordise our chances of commercial success) is one that in no way impedes *other* vendors from implementing it | 21:59 |
| lkcl | and, hilariously, there is no technical reason why VSX should not be SVP64-contextualised | 22:00 |
| lxo | well, yeah, but... see how troublesome the realization was that the v2 ABI actually requires VSX registers, which is well in line with the joke that the C in IBM stands for choice | 22:00 |
| programmerjake[m | as sv is currently formulated, it is not compatible with vmx | 22:01 |
| lxo | I wonder how much control IBM has over the OpenPOWER Foundation | 22:01 |
| programmerjake[m | i'd expect ibm has more control than anyone else...but I don't know to which extent | 22:02 |
| lxo | what does SVP stand for? Simple-V P??? Processing? | 22:02 |
| lkcl | programmerjake[m: we just never added VSX registers to SVP64. conceptually it is perfectly possible: i just don't want us investing the time or energy in that because it's time and money wasted for no benefit, in fact harm | 22:02 |
| lkcl | Simple-V Prefix | 22:02 |
| programmerjake[m | SimpleV prefix | 22:02 |
| lxo | aha | 22:02 |
| lkcl | SVP64: 64-bit Simple-V Prefixing | 22:03 |
| lkcl | format | 22:03 |
| lxo | and the V is for vector, nothing to do with the V in RISC-V, right? | 22:03 |
| lxo | at first I thought it was. I still find the similarity confusing at times | 22:03 |
| programmerjake[m | it's not compatible because SV and VSX contradict each other on how FP registers are laid out | 22:03 |
| programmerjake[m | hence why I've been pushing for us to at least make them compatible | 22:04 |
| lkcl | programmerjake[m, no.\ | 22:04 |
| lkcl | i've said this multiple times | 22:04 |
| lkcl | accommodating SIMD in any form is a major red flag | 22:05 |
| lkcl | if someone else wants to do that, _great_ | 22:05 |
| programmerjake[m | lkcl: compatible does *not* mean we implement VMX, it means someone *could* if they wanted | 22:06 |
| lkcl | we cannot afford the time or the resources right now and i would like it to be so excruciatingly painful that people do everything they can instead to convert away from VSX | 22:06 |
| lkcl | in 8-10 years i'd like to see the OpenPOWER Foundation declare VSX - in its entirety - to be legacy, just like load-store-multiple | 22:07 |
| programmerjake[m | well, I think we're just shooting ourselves in the foot then... | 22:07 |
| lkcl | the primary mass volume markets are Android, ChromeOS and Graphics Cards | 22:07 |
| lkcl | these are embedded markets where we do not have to be compatible with any GNU/Linux distro in any way shape or form | 22:08 |
| lkcl | this gets us revenue to fund sustainable development | 22:08 |
| lkcl | where accommodating VSX in any way right now severely jeapordises our chances of even getting to that point | 22:09 |
| lxo | what if OpenPOWER Foundation doesn't integrate SVP64? do we have any licenses we might need to implement the parts of the PowerPCv3.0B that we intend to? | 22:09 |
| lkcl | we're under both time and funding pressure to deliver | 22:09 |
| programmerjake[m | I'm fine with and agree with declaring VMX to be legacy, but having our spec be incompatible such that a cpu can't use both VMX and SV is just being anal imho | 22:09 |
| lkcl | lxo: the V3.0C and v3.1 specifications have wording which allows us an "escape route" | 22:10 |
| lkcl | it'll be a damn nuisance but it doesn't jeapordise our route to funding by making the entire venture critically dependent on OPF ratification | 22:10 |
| lkcl | programmerjake[m: other vendors can do so if they choose, and they can learn from that mistake | 22:11 |
| lxo | or are we at risk of a dick move by IBM, along the lines of "nice architecture you got there. it would suck if our lawyers had to send you C&D letters over some unspecified patents"? | 22:11 |
| lkcl | lxo: the EULA is very clear on this - they've already set the terms and conditions | 22:11 |
| lkcl | if they tried that we would be able to sue them. something to be avoided, but hey | 22:12 |
| * lxo is not aware of any EULA | 22:12 | |
| lkcl | IBM has already agreed to... ah 1 sec | 22:12 |
| lkcl | https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/ | 22:12 |
| lkcl | there is specific wording in there precisely because people were afraid of exactly what you hypothesised | 22:12 |
| lkcl | the OPF therefore got IBM to license its patent pool, royalty-free on two conditions: | 22:13 |
| lkcl | 1) that implementations are "Compliant" | 22:13 |
| lxo | I'm glad my paranoia is not exclusive ;-D | 22:13 |
| lkcl | 2) that under no circumstances do you engage in litigation against OPF Members | 22:13 |
| lkcl | lol | 22:13 |
| lxo | argh. please enable javascript and reload the page | 22:14 |
| lxo | why oh why, cloudflare? | 22:14 |
| lkcl | mopar426_ed, https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=ppc64-gdb-gcc;hb=HEAD | 22:14 |
| lxo | internet archive, here we go... | 22:14 |
| programmerjake[m | lkcl: I strongly disagree with having our SV spec be incompatible with VMX just because we didn't take the 2-3 days needed to adjust it to work with VMX. I think the OPF will likely agree with me -- having our spec be incompatible just for the sake of laziness/because we can is likely to get our spec proposal rejected | 22:16 |
| lxo | I suppose excluding altivec/vmx and vsx yields one of the compliancy subsets | 22:16 |
| lkcl | programmerjake[m: we've been over this, many times. the sequential numbering is an essential part of preserving the scalar-vector access | 22:17 |
| lkcl | VSX by having jumping numbering has to take a back seat. | 22:17 |
| programmerjake[m | lkcl: think of it this way -- you want IBM to be inclined to implement SVP64 in their Power server cpus, right? they won't if it breaks VMX | 22:18 |
| lkcl | now, it turns out that *if* you use the SV-REMAP system you *can* get numbering in VSX order but we are not going to add 128 bit datapaths as our very first architecture in so it is a moot point anyway | 22:18 |
| lkcl | it won't be impossible it will just require a f*** ton of money | 22:18 |
| lkcl | which IBM has and we don't | 22:19 |
| lkcl | they've already set the barrier insanely high, i see no good reason why we should jump that far ahead to something that would require a massive team and five times as much investment as we're currently asking for | 22:20 |
| programmerjake[m | we don't need 128-bit datapaths to make it VMX compatible -- VMX compatible != VMX is implemented | 22:21 |
| lkcl | VMX requires 128 bit datapaths to achieve anything remotely similar to IBM's level of performance | 22:21 |
| lxo | couldn't we just regard 128-bit FP regs as pairs of 64-bit vector elements? | 22:21 |
| lkcl | i've said this many many times: if we try to accommodate that it severely compromises the internal architecture | 22:22 |
| lkcl | lxo: that requires that we *have* paired 64-bit LD/ST arrangements | 22:22 |
| lxo | it would amount to shifting our FP register numbering right by one bit | 22:22 |
| lxo | huh? | 22:22 |
| programmerjake[m | basically rewrite a few wires in the decoder and we're done. no massive cpu changes needed | 22:23 |
| lkcl | to give you an example: one of the early micro-architectures we were going to split the 64-bit regfiles into 32-bit "pairs" | 22:23 |
| programmerjake[m | rewire* | 22:23 |
| lkcl | then stripe them | 22:23 |
| lkcl | using QTY 4x 4R1W 32-bit-wide *completely* independent regfiles | 22:23 |
| lkcl | this suits the sequential nature of SV extremely well | 22:24 |
| lkcl | the other reason for not doing it: we're out of time. | 22:24 |
| lkcl | we're a year behind | 22:25 |
| lkcl | we *cannot afford* the time taken on this discussion. | 22:25 |
| lkcl | again | 22:25 |
| lkcl | we need to be *implementing* what is in the spec | 22:25 |
| lkcl | and we need people to help doing that | 22:25 |
| programmerjake[m | requiring paired ld/st: not needed -- we're not implementing VMX. | 22:25 |
| lkcl | exactly. and we're not going to discuss changing the specification to try to accommodate it | 22:26 |
| lkcl | *because we do not have time* | 22:26 |
| lkcl | again | 22:26 |
| lkcl | we need people - everyone - all of us - to focus on *implementing* | 22:26 |
| lkcl | the time for discussion of changes is over, for this round. | 22:26 |
| programmerjake[m | well, I guess that means we don't have time to not shoot ourselves in the foot | 22:26 |
| lkcl | i've put the implementation page up | 22:27 |
| lkcl | correct. | 22:27 |
| lxo | lkcl, this is actually no different from the very recent changes of 'now only registers multiple of X are accessible' | 22:27 |
| lkcl | because the discussion is over, and we are on to "implementing" round | 22:27 |
| lxo | err s/accessible/nameable/ | 22:27 |
| programmerjake[m | lxo: yes, my point exactly! | 22:27 |
| lkcl | there is nothing to stop anyone in the future from proposing an augmentation of SV to do SVP64-VSX | 22:28 |
| lxo | just make X = 2, and let the odd registers be the other half of VSX registers, voila | 22:28 |
| lkcl | lxo: that's what REMAP does. | 22:28 |
| lxo | point is if we specify that we also solve the problem of ABI compatibility | 22:28 |
| programmerjake[m | odd regs are other half of vmx regs: yes!! | 22:29 |
| lxo | because then we *can* comply with the ABI using only SVP64 | 22:29 |
| lkcl | it allows - amongst many other things - adding of an arbitrary offset to the SVSTATE.srcstep | 22:29 |
| lkcl | lxo: please can you raise that as a bugreport, so that it's documented? | 22:29 |
| lkcl | but - and programmerjake[m please please for goodness sake listen - it is NOT going to be implemented IN THIS ROUND | 22:30 |
| programmerjake[m | well, if we use the proposed modification, we don't need REMAP so we can cut it if we run short on time | 22:30 |
| lkcl | capture the idea and please *move on* | 22:30 |
| lkcl | no, no and no. *not in this round* | 22:30 |
| lkcl | capture the idea, then please drop it entirely, and help implement *this round* | 22:30 |
| programmerjake[m | k, moving on... | 22:31 |
| lkcl | we will come *back* to evaluation *later*. | 22:31 |
| lkcl | please. | 22:31 |
| lkcl | we *do not have time* | 22:31 |
| lkcl | we need to fundamentally focus on getting the current implementation done as fast as possible | 22:32 |
| lkcl | i would really appreciate it if you could help with that, programmerjake[m | 22:32 |
| programmerjake[m | lxo: what commands did you use to build gcc? I've tried several variations and it never worked for me... | 22:32 |
| programmerjake[m | I was trying to build a cross compiler for x86 to ppc64le | 22:35 |
| lkcl | programmerjake[m, it shouuuld be similar to the options on gdb build https://libre-soc.org/HDL_workflow/ | 22:36 |
| lkcl | it's necessary to specify the host and the target | 22:36 |
| mopar426_ed | lkcl I'm running the ppc64-gdb-gcc script, so far so good. | 22:36 |
| lkcl | interesting! https://github.com/narke/gcc-cross-compiler | 22:36 |
| lkcl | mopar426_ed: oh ha, i left "-n" in the "make -n install" | 22:37 |
| lkcl | doh | 22:37 |
| lkcl | so it will build but not actually install | 22:37 |
| lkcl | you can correct that manually with sudo bash (or other root prompt method) | 22:37 |
| lkcl | then "cd gdb-8.3/build" and "make install" | 22:37 |
| mopar426_ed | no stress, I'll check it when it finishes | 22:38 |
| lkcl | i added make -n because i have gdb 9.3 already installed and i didn't want it overwritten | 22:39 |
| programmerjake[m | thx, I'll try it out in a little bit | 22:39 |
| mopar426_ed | I figured that, thanks! | 22:39 |
| lkcl | programmerjake[m, or it could be worth examining to see what it does | 22:39 |
| mopar426_ed | I actually have 9.3 installed as well | 22:39 |
| lkcl | mopar426_ed, did the pythonic stuff do ok? | 22:40 |
| lkcl | ah right! | 22:40 |
| lkcl | ok well then you don't need (or want)... ok you need the gcc cross-compiler to match gdb (which comes with binutils) | 22:40 |
| lkcl | the unit tests are not sophisticated enough to specify "a version of gcc" | 22:40 |
| lkcl | 1 sec.... | 22:40 |
| lxo | bug 610 | 22:41 |
| mopar426_ed | yes, and since I got gcc 8 I was building gdb 8 as well | 22:41 |
| lkcl | mopar426_ed: here https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simulator/program.py;hb=HEAD#l61 | 22:41 |
| lkcl | lxo: star | 22:41 |
| lxo | lkcl, well, if we don't do that now, it will be very hard to introduce it later, but... whatever | 22:42 |
| lkcl | you see there, line 61, it simply execs powerpc64-linux-gnu-objcopy | 22:42 |
| lkcl | lxo: if during the "evaluation round" (which naturally comes *after* the "implementation" round is completed) | 22:43 |
| lkcl | we take stock and find that we do in fact need to change that, then we have a list of ideas to evaluate | 22:43 |
| lxo | programmerjake[m, what's the failure mode? I haven't done more than plain configure in native builds on our build server. for cross builds, I've used --target=ppc64-linux-gnu | 22:44 |
| lkcl | the gdb cross-build is this: | 22:45 |
| lkcl | ../configure --srcdir=.. --host=x86_64-linux --target=powerpc64-linux-gnu | 22:45 |
| lkcl | bitbake (openembedded), hilariously, has scripts which allow you to run (and test) gcc compiling under qemu! | 22:46 |
| lkcl | so you can either actually compile *the entire compiler* as native under qemu | 22:46 |
| lkcl | or | 22:46 |
| lkcl | compile the cross-compiler but then run the unit tests under qemu-cmdline | 22:47 |
| lkcl | or | 22:47 |
| lkcl | have it ssh into a native machine... :) | 22:47 |
| lkcl | it's awesome, scary, and hilarious, all at the same time | 22:47 |
| lkcl | that's interesting https://github.com/narke/gcc-cross-compiler/blob/master/toolchain.py#L102 | 22:49 |
| lkcl | i wonder why that's ppc64-linux-gnu | 22:49 |
| lkcl | where gdb (and debian) use powerpc64-linux-gnu | 22:49 |
| lkcl | straange | 22:49 |
| mopar426_ed | cool, I'll continue my setup tomorrow, need to use the rest of the evening I've to update some CI/CD. good night all! | 22:50 |
| lxo | qemu cross-bootstrapping is pretty cool. the rest is not unheard of with dejagnu. dejagnu can actually test with different build, host and target, running the cross-compiler remotely on a host machine, and running the tests remotely on a target machine | 22:51 |
| lkcl | mopar426_ed, night | 22:51 |
| lkcl | lxo: niiice | 22:51 |
| lxo | lkcl, ppc64 is shorthand for powerpc64, config.sub normalizes it | 22:52 |
| lkcl | ahh | 22:52 |
| * lkcl needs to get up and walk around. | 22:53 | |
| segher | some OSes use ppc64 in the uname | 23:12 |
| segher | distasteful, but :-) | 23:12 |
| segher | lxo: it is perhaps more common to run the target in an emulator locally, but yeah, dg can do it all | 23:14 |
| lxo | *nod* | 23:18 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!