Tuesday, 2021-02-02

programmerjake[mah, ok. that works00:02
lkcllxo: we need to define a way to allow implicit-destination regs to be overloaded differently from src.  for example, LD-with-update.15:35
lkclany thoughts?  one option is "/" as a separator.  ldu RT, RA-dest/RA-src, RB for example, what do you think?15:36
lkclLD/ST-with-update is the only one in OpenPOWER v3.0B however when adding e.g. bitmanip this is going to be important and more prevalent.15:37
lxolkcl, I can't figure out what the behavior is that this would express16:25
lkclLD-with-update will compute Effective Address (EA) equal to RA+RB16:34
lkclthen *overwrite* RA with that computed address16:34
lkclhowever... that means that RA, which was a source, is also a destination.16:35
lkclwe have room in SVP64 to make RA-as-a-source a *SEPARATE* register from RA-as-a-destination16:35
lkclby applying completely separate EXTRA2 prefixes.16:35
lkcl* RT as a destination has one EXTRA216:36
lkcl* RB as a source has a 2nd EXTRA216:36
lkcl* RA-as-a-source has a 3rd EXTRA216:36
lkcl* RA-as-a-DESTINATION has a 4th EXTRA216:36
lkclsee https://libre-soc.org/openpower/isa/fixedload/ for the pseudocode16:37
lkclit is as if we modified lbzu to be "lbzux RT, RA, RA, RB"16:39
lkcl2 source registers16:39
lkcl2 destination registers16:39
lkclit's just that in OpenPOWER v3.0B, one of those sources (RA) is implicitly also the destination16:39
lkclchanging the asm from 3 parameters to 4 parameters however is.. not a good idea.  it no longer matches v3.0B syntax16:40
lxogot it, thanks16:44
lxoI recommend changing the opcode and adding the extra parameter.  instead of u, use another letter that doesn't clash with other letters that appear in load and store opcodes, and that ideally expands to something that suggests the behavior16:48
lxois m taken in this sense?16:48
lkclmmm... changing the opcode breaks one of the fundamental rules of SV.  even though it is "just" an opcode name, the key fundamental principle is to "augment" the scalar ISA.17:33
lkclalso, changing the opcode (effectively creating a new opcode) implies that the underlying behaviour is new / different17:34
lkclwe'll get difficult questions that will be hard to answer / justify when presenting it to the OpenPOWER ISA WG17:34
lkcland, it would be necessary to add the changed opcode here17:37
lkclwhich in turn means it needs to be added to the OpenPOWER v3.N (future document)17:37
lkcland that's a discussion i *really* do not want to get into with the OPF ISA WG.17:38
lkclmind you even the idea "lbux RT, RA-src/RA-dest, RB" will be difficult to justify17:40
lkclbut the prefixing/embedding "sv.{opcode}/augment1/augment2/..." probably less so17:40
lkclfor example:17:57
lkcl     sv.lbux/RA-as-dest=5.v  1,2,317:57
lkclis declaring, "RT=1, RA=2, RB=3, but RA-as-a-dest is a vector and it is r5"17:58
programmerjake[miirc you can't use those particular registers, RA-as-a-dest has to have the same 5 lsb bits as RA, only the top 2 bits can differ18:01
programmerjake[mwhich is part of the reason why I think it would be better (waay less complex) for the compiler to always have RA and RA-as-a-dest be the same register, since having the lower 5 bits the same is likely quite complex of a register constraint18:03
programmerjake[mto implement in the register allocator18:04
lxoerr, I just meant changing the mnemonic, not the opcode, sorry.  anyway, the argument that changing the underlying behavior is undesirable is orthogonal to the syntax used to express it.  if the behavior is changed in a relevant way, we might as well be upfront about it18:19
lxowhich is to say I can't perceive either alternative as obviously superior to the other.  I mean, using an alternate mnemonic, or one augmented by slash-whatever18:20
programmerjake[mI currently own libre-gpu.org and libre-cpu.org, do we want to keep them or should I just let them expire?18:27
lxono opinion on that.  we should probably get back to the conversation on *pu.  it just occured to me that hapPU makes for a lovely-sounding name18:30
lxocan you imagine computers shipping with a happy-you inside?  who wouldn't want one? :-)18:38
programmerjake[mlkcl any opinion on the domain names?18:38
lxogonna miss tonight's virtual coffee :-(  I'm already sleeping at the keyboard.  sorry18:42
programmerjake[mwell, sleep well, we'll miss you18:42
lxoprogrammerjake[m, I've refreshed the libre-soc branch in my gcc tree, btw.  it probably has the patch you wanted18:42
programmerjake[mon the talos server or on git.libre-soc.org?18:43
lxooh, yeah, I'm yet to push it to our git server.  on the talos server only for now18:43
lxoI still have a handful of ada regressions I wanted to at least have a look at before making it widely available.  ada is pretty good at exercising paths in gcc that other languages don't, and it has a very extensive publicly-available testsuite18:45
programmerjake[mah, ok18:46
lxoanother issue is policy around non-fast-forward updates.  I'm using stgit, which is sort of like rebasing all the time, but I could be convinced to do merges instead18:47
programmerjake[mwell, I'll probably try and build it later today18:47
lxostgiit makes it reasonably easy to manage a patchset as it evolves towards contributing it, but it doesn't quite retain the development history that way18:48
programmerjake[msince gcc upstream uses rebases for all commits anyway (iirc) I think we could probably make an exception to the no-force-pushes guidance, lkcl, what do you think?18:49
lxo*nod*, gcc git enforces linear history19:00
lkclprogrammerjake[m: i mentioned already that the assembler writer or programmer writer or compiler writer, if they find the concept too difficult, may simply set the EXTRA2 for RA-as-src equal to the EXTRA2 for RA-as-dest19:25
lkcllxo: yes i understood "changing the opcode" to mean "change the mnemonic".19:26
programmerjake[myup, I'm just doing some more advocating19:27
lkclthe advantage of what you suggest does mean that this issue "goes away"19:29
lkclhmm hmmm we're doing a hybrid cpu-gpu-vpu, the other domains would be misleading19:31
programmerjake[mwhile your here: lkcl any opinion on the ^ domain names?19:31
programmerjake[mor, is that what you just answered19:32
programmerjake[mi would have to say that a large part of what makes our project distinct is we're doing a gpu at all, basically everyone else does only libre cpus. vpu is often assumed to be part of gpu. so libre-gpu is much more applicable...19:35
lkclthe message sent by saying "it's a GPU" is unfortunately to say "it's incapable of being a CPU".19:36
programmerjake[mthough that is changing .. the risc-v gpu project19:36
lkcloh dear, they didn't.19:36
programmerjake[myeah, ok19:36
lkcloh wait - do you mean pixilica's project?  i spoke to Atif, he said that was an out-of-date latency on an article from 2 years ago (!)19:37
lkclyes, that one.  it's literally 2 years out-of-date!19:37
programmerjake[mso, wait, they're not doing that anymore?19:38
lkclhe paid SiFive USD 75,000 to license their help and they screwed him over19:38
lkclhe was absolutely livid.  that was his personal money.19:39
programmerjake[mwell, that explains why they referred to Libre-RISC-V and not Libre-SOC19:39
lkclhe's since moved on to a more general-purpose concept, which he presented at siggraph 202019:39
programmerjake[mah, ok19:40
programmerjake[mif you have any links it would be interesting reading, maybe send to libre-soc-misc19:41
programmerjake[mthe siggraph thing19:41
lkclgood idea, done19:42
lkclmy friend david will be along tonight btw20:19
lkclprogrammerjake[m, ^21:59

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!