Thursday, 2021-03-04

lkcllxo: it's rather unfortunate that david's not quite fully grasping the significant of SV.19:50
lkclwhat would you suggest here?19:50
lxomaybe that it shouldn't have been me making the introduction :-(20:37
lxothere's some history of hostility towards rms and myself there20:38
lxohopefully that's not the reason for this reaction, though20:38
lxomaybe it's just about the complexity this will add to a port that already has a lot of it20:41
lxomaybe he's just dismissive for not realizing how far we are into getting buy-in from the openpower foundation20:42
lxoor maybe we aren't getting it and we don't know it but he does20:43
*** ed97 is now known as Mopar_ed20:59
lkcllxo: the assessment "it's like the NXP SPE SIMD extension" has me deeply concerned21:27
lkclif there are people inside IBM discussing it and they think it's a variant of SSE2 that's simply alarming21:28
mopar426_edhi guys! I finally got some free time again, when I try the make install for soc I get:21:30
mopar426_edpython3 develop --user # yes, develop, not install21:30
mopar426_edusage: [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]21:30
mopar426_ed   or: --help [cmd1 cmd2 ...]21:30
mopar426_ed   or: --help-commands21:30
mopar426_ed   or: cmd --help21:30
mopar426_ederror: option --user not recognized21:30
mopar426_edmake: *** [Makefile:17: develop] Error 121:31
mopar426_edhas any of you run into this?21:31
lkclmopar426_ed, hi.  do stick around if you can with the chat :)21:31
lkcli've never used "--user"21:31
lkcli've only ever done straight "python3 develop" under root21:31
lkclcan you do "python3 --version" ? what does it say?21:31
mopar426_edI just removed --user from the Makefile and it is going through21:32
lkclMakefile? moo?21:32
* lkcl goes to check21:32
lkclah yes i see21:32
* lkcl removing that21:32
lkclmopar426_ed: thanks for spotting that21:33
lkclbtw do make sure you do the installs in the exact order21:33
lkcllisted in HDL_workflow21:33
lkclotherwise 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
mopar426_edhaven't seen that page yet, I'm checking from the "5.1 quick peek at the code"21:34
lkclok 1 sec21:34
mopar426_edthanks, I'll read through21:34
lkclthe last thing you want is for some dependency to drag in a downloaded (out-of-date) version of nmigen-0.1 or something21:34
lkclyou _can_ use these automated scripts if you want21:35
lkclthis one gets every-dependency-you-need-in-one-hit21:35
mopar426_edawesome, I'll check those. that should save me some time.21:36
lkclthis one does *some* of the python-based stuff21:36
lkcland we really should do one for getting gdb and powerpc64-gnu-linux-gcc as well21:36
lkclgdb you _have_ to get from source, because nobody does a cross-compiler debian package of binutils+gdb21:37
lkclhmm i'll write one of those now21:40
lkclmopar426_ed: are you using debian buster by chance?21:41
mopar426_edyes, I got the gdb tarball and will compile it for powerpc21:42
mopar426_edyes, I use buster21:42
lkclok great.  that's... gcc-8-powerpc64-linux-gnu, right?21:43
lkclor does it have gcc-9 ?  (i use debian/testing so i can't tell)21:43
mopar426_edno buster only has 821:44
lkclokaay then i'll put that into the script.  thank you21:45
mopar426_edno problem21:46
* lkcl just testing it21:48
lxolkcl, 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 architecture21:50
lxowhich is still very unfortunate, because SPE turned out to be an evolutionary dead end, precisely because its extensions did not get integrated21:51
lkcltrue... 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
lkclto 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
lxowell...  we are departing from altivec and vsx21:56
lxoeven if we don't regard it as core openpower, I gather he doesn't draw the line at the same place21:57
lkclnot departing: just... not implementing.21:58
lkclnow, *other vendors* may choose to make a different call there.21:58
lkclthe 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 it21:59
lkcland, hilariously, there is no technical reason why VSX should not be SVP64-contextualised22:00
lxowell, 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 choice22:00
programmerjake[mas sv is currently formulated, it is not compatible with vmx22:01
lxoI wonder how much control IBM has over the OpenPOWER Foundation22:01
programmerjake[mi'd expect ibm has more control than anyone else...but I don't know to which extent22:02
lxowhat does SVP stand for?  Simple-V P???  Processing?22:02
lkclprogrammerjake[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 harm22:02
lkclSimple-V Prefix22:02
programmerjake[mSimpleV prefix22:02
lkclSVP64: 64-bit Simple-V Prefixing22:03
lxoand the V is for vector, nothing to do with the V in RISC-V, right?22:03
lxoat first I thought it was.  I still find the similarity confusing at times22:03
programmerjake[mit's not compatible because SV and VSX contradict each other on how FP registers are laid out22:03
programmerjake[mhence why I've been pushing for us to at least make them compatible22:04
lkclprogrammerjake[m, no.\22:04
lkcli've said this multiple times22:04
lkclaccommodating SIMD in any form is a major red flag22:05
lkclif someone else wants to do that, _great_22:05
programmerjake[mlkcl: compatible does *not* mean we implement VMX, it means someone *could* if they wanted22:06
lkclwe 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 VSX22:06
lkclin 8-10 years i'd like to see the OpenPOWER Foundation declare VSX - in its entirety - to be legacy, just like load-store-multiple22:07
programmerjake[mwell, I think we're just shooting ourselves in the foot then...22:07
lkclthe primary mass volume markets are Android, ChromeOS and Graphics Cards22:07
lkclthese are embedded markets where we do not have to be compatible with any GNU/Linux distro in any way shape or form22:08
lkclthis gets us revenue to fund sustainable development22:08
lkclwhere accommodating VSX in any way right now severely jeapordises our chances of even getting to that point22:09
lxowhat 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
lkclwe're under both time and funding pressure to deliver22:09
programmerjake[mI'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 imho22:09
lkcllxo: the V3.0C and v3.1 specifications have wording which allows us an "escape route"22:10
lkclit'll be a damn nuisance but it doesn't jeapordise our route to funding by making the entire venture critically dependent on OPF ratification22:10
lkclprogrammerjake[m: other vendors can do so if they choose, and they can learn from that mistake22:11
lxoor 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
lkcllxo: the EULA is very clear on this - they've already set the terms and conditions22:11
lkclif they tried that we would be able to sue them.  something to be avoided, but hey22:12
* lxo is not aware of any EULA22:12
lkclIBM has already agreed to... ah 1 sec22:12
lkclthere is specific wording in there precisely because people were afraid of exactly what you hypothesised22:12
lkclthe OPF therefore got IBM to license its patent pool, royalty-free on two conditions:22:13
lkcl1) that implementations are "Compliant"22:13
lxoI'm glad my paranoia is not exclusive ;-D22:13
lkcl2) that under no circumstances do you engage in litigation against OPF Members22:13
lxoargh.  please enable javascript and reload the page22:14
lxowhy oh why, cloudflare?22:14
lxointernet archive, here we go...22:14
programmerjake[mlkcl: 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 rejected22:16
lxoI suppose excluding altivec/vmx and vsx yields one of the compliancy subsets22:16
lkclprogrammerjake[m: we've been over this, many times.  the sequential numbering is an essential part of preserving the scalar-vector access22:17
lkclVSX by having jumping numbering has to take a back seat.22:17
programmerjake[mlkcl: 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 VMX22:18
lkclnow, 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 anyway22:18
lkclit won't be impossible it will just require a f*** ton of money22:18
lkclwhich IBM has and we don't22:19
lkclthey'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 for22:20
programmerjake[mwe don't need 128-bit datapaths to make it VMX compatible -- VMX compatible != VMX is implemented22:21
lkclVMX requires 128 bit datapaths to achieve anything remotely similar to IBM's level of performance22:21
lxocouldn't we just regard 128-bit FP regs as pairs of 64-bit vector elements?22:21
lkcli've said this many many times: if we try to accommodate that it severely compromises the internal architecture22:22
lkcllxo: that requires that we *have* paired 64-bit LD/ST arrangements22:22
lxoit would amount to shifting our FP register numbering right by one bit22:22
programmerjake[mbasically rewrite a few wires in the decoder and we're done. no massive cpu changes needed22:23
lkclto 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
lkclthen stripe them22:23
lkclusing QTY 4x 4R1W 32-bit-wide *completely* independent regfiles22:23
lkclthis suits the sequential nature of SV extremely well22:24
lkclthe other reason for not doing it: we're out of time.22:24
lkclwe're a year behind22:25
lkclwe *cannot afford* the time taken on this discussion.22:25
lkclwe need to be *implementing* what is in the spec22:25
lkcland we need people to help doing that22:25
programmerjake[mrequiring paired ld/st: not needed -- we're not implementing VMX.22:25
lkclexactly.  and we're not going to discuss changing the specification to try to accommodate it22:26
lkcl*because we do not have time*22:26
lkclwe need people - everyone - all of us - to focus on *implementing*22:26
lkclthe time for discussion of changes is over, for this round.22:26
programmerjake[mwell, I guess that means we don't have time to not shoot ourselves in the foot22:26
lkcli've put the implementation page up22:27
lxolkcl, this is actually no different from the very recent changes of 'now only registers multiple of X are accessible'22:27
lkclbecause the discussion is over, and we are on to "implementing" round22:27
lxoerr s/accessible/nameable/22:27
programmerjake[mlxo: yes, my point exactly!22:27
lkclthere is nothing to stop anyone in the future from proposing an augmentation of SV to do SVP64-VSX22:28
lxojust make X = 2, and let the odd registers be the other half of VSX registers, voila22:28
lkcllxo: that's what REMAP does.22:28
lxopoint is if we specify that we also solve the problem of ABI compatibility22:28
programmerjake[modd regs are other half of vmx regs: yes!!22:29
lxobecause then we *can* comply with the ABI using only SVP6422:29
lkclit allows - amongst many other things - adding of an arbitrary offset to the SVSTATE.srcstep22:29
lkcllxo: please can you raise that as a bugreport, so that it's documented?22:29
lkclbut - and programmerjake[m please please for goodness sake listen - it is NOT going to be implemented IN THIS ROUND22:30
programmerjake[mwell, if we use the proposed modification, we don't need REMAP so we can cut it if we run short on time22:30
lkclcapture the idea and please *move on*22:30
lkclno, no and no.  *not in this round*22:30
lkclcapture the idea, then please drop it entirely, and help implement *this round*22:30
programmerjake[mk, moving on...22:31
lkclwe will come *back* to evaluation *later*.22:31
lkclwe *do not have time*22:31
lkclwe need to fundamentally focus on getting the current implementation done as fast as possible22:32
lkcli would really appreciate it if you could help with that, programmerjake[m22:32
programmerjake[mlxo: what commands did you use to build gcc? I've tried several variations and it never worked for me...22:32
programmerjake[mI was trying to build a cross compiler for x86 to ppc64le22:35
lkclprogrammerjake[m, it shouuuld be similar to the options on gdb build
lkclit's necessary to specify the host and the target22:36
mopar426_edlkcl I'm running the ppc64-gdb-gcc script, so far so good.22:36
lkclmopar426_ed: oh ha, i left "-n" in the "make -n install"22:37
lkclso it will build but not actually install22:37
lkclyou can correct that manually with sudo bash (or other root prompt method)22:37
lkclthen "cd gdb-8.3/build" and "make install"22:37
mopar426_edno stress, I'll check it when it finishes22:38
lkcli added make -n because i have gdb 9.3 already installed and i didn't want it overwritten22:39
programmerjake[mthx, I'll try it out in a little bit22:39
mopar426_edI figured that, thanks!22:39
lkclprogrammerjake[m, or it could be worth examining to see what it does22:39
mopar426_edI actually have 9.3 installed as well22:39
lkclmopar426_ed, did the pythonic stuff do ok?22:40
lkclah right!22:40
lkclok well then you don't need (or want)... ok you need the gcc cross-compiler to match gdb (which comes with binutils)22:40
lkclthe unit tests are not sophisticated enough to specify "a version of gcc"22:40
lkcl1 sec....22:40
lxobug 61022:41
mopar426_edyes, and since I got gcc 8 I was building gdb 8 as well22:41
lkclmopar426_ed: here;a=blob;f=src/soc/simulator/;hb=HEAD#l6122:41
lkcllxo: star22:41
lxolkcl, well, if we don't do that now, it will be very hard to introduce it later, but... whatever22:42
lkclyou see there, line 61, it simply execs powerpc64-linux-gnu-objcopy22:42
lkcllxo: if during the "evaluation round" (which naturally comes *after* the "implementation" round is completed)22:43
lkclwe take stock and find that we do in fact need to change that, then we have a list of ideas to evaluate22:43
lxoprogrammerjake[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-gnu22:44
lkclthe gdb cross-build is this:22:45
lkcl../configure --srcdir=.. --host=x86_64-linux --target=powerpc64-linux-gnu22:45
lkclbitbake (openembedded), hilariously, has scripts which allow you to run (and test) gcc compiling under qemu!22:46
lkclso you can either actually compile *the entire compiler* as native under qemu22:46
lkclcompile the cross-compiler but then run the unit tests under qemu-cmdline22:47
lkclhave it ssh into a native machine... :)22:47
lkclit's awesome, scary, and hilarious, all at the same time22:47
lkclthat's interesting
lkcli wonder why that's ppc64-linux-gnu22:49
lkclwhere gdb (and debian) use powerpc64-linux-gnu22:49
mopar426_edcool, 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
lxoqemu 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 machine22:51
lkclmopar426_ed, night22:51
lkcllxo: niiice22:51
lxolkcl, ppc64 is shorthand for powerpc64, config.sub normalizes it22:52
* lkcl needs to get up and walk around.22:53
seghersome OSes use ppc64 in the uname23:12
segherdistasteful, but :-)23:12
segherlxo: it is perhaps more common to run the target in an emulator locally, but yeah, dg can do it all23:14

Generated by 2.17.1 by Marius Gedminas - find it at!