| programmerjake[m | ah, ok. that works | 00:02 |
|---|---|---|
| lkcl | lxo: we need to define a way to allow implicit-destination regs to be overloaded differently from src. for example, LD-with-update. | 15:35 |
| lkcl | any thoughts? one option is "/" as a separator. ldu RT, RA-dest/RA-src, RB for example, what do you think? | 15:36 |
| lkcl | LD/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 |
| lxo | lkcl, I can't figure out what the behavior is that this would express | 16:25 |
| lkcl | LD-with-update will compute Effective Address (EA) equal to RA+RB | 16:34 |
| lkcl | then *overwrite* RA with that computed address | 16:34 |
| lkcl | however... that means that RA, which was a source, is also a destination. | 16:35 |
| lkcl | we have room in SVP64 to make RA-as-a-source a *SEPARATE* register from RA-as-a-destination | 16:35 |
| lkcl | by applying completely separate EXTRA2 prefixes. | 16:35 |
| lkcl | * RT as a destination has one EXTRA2 | 16:36 |
| lkcl | * RB as a source has a 2nd EXTRA2 | 16:36 |
| lkcl | * RA-as-a-source has a 3rd EXTRA2 | 16:36 |
| lkcl | * RA-as-a-DESTINATION has a 4th EXTRA2 | 16:36 |
| lkcl | see https://libre-soc.org/openpower/isa/fixedload/ for the pseudocode | 16:37 |
| lkcl | it is as if we modified lbzu to be "lbzux RT, RA, RA, RB" | 16:39 |
| lkcl | 2 source registers | 16:39 |
| lkcl | 2 destination registers | 16:39 |
| lkcl | it's just that in OpenPOWER v3.0B, one of those sources (RA) is implicitly also the destination | 16:39 |
| lkcl | changing the asm from 3 parameters to 4 parameters however is.. not a good idea. it no longer matches v3.0B syntax | 16:40 |
| lxo | got it, thanks | 16:44 |
| lxo | *thinks* | 16:44 |
| lxo | I 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 behavior | 16:48 |
| lxo | is m taken in this sense? | 16:48 |
| lkcl | mmm... 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 |
| lkcl | also, changing the opcode (effectively creating a new opcode) implies that the underlying behaviour is new / different | 17:34 |
| lkcl | we'll get difficult questions that will be hard to answer / justify when presenting it to the OpenPOWER ISA WG | 17:34 |
| lkcl | and, it would be necessary to add the changed opcode here | 17:37 |
| lkcl | https://libre-soc.org/openpower/isa/fixedload/ | 17:37 |
| lkcl | which in turn means it needs to be added to the OpenPOWER v3.N (future document) | 17:37 |
| lkcl | and that's a discussion i *really* do not want to get into with the OPF ISA WG. | 17:38 |
| lkcl | mind you even the idea "lbux RT, RA-src/RA-dest, RB" will be difficult to justify | 17:40 |
| lkcl | but the prefixing/embedding "sv.{opcode}/augment1/augment2/..." probably less so | 17:40 |
| lkcl | for example: | 17:57 |
| lkcl | sv.lbux/RA-as-dest=5.v 1,2,3 | 17:57 |
| lkcl | is declaring, "RT=1, RA=2, RB=3, but RA-as-a-dest is a vector and it is r5" | 17:58 |
| programmerjake[m | iirc 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 differ | 18:01 |
| programmerjake[m | which 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 constraint | 18:03 |
| programmerjake[m | to implement in the register allocator | 18:04 |
| lxo | err, 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 it | 18:19 |
| lxo | which 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-whatever | 18:20 |
| programmerjake[m | I currently own libre-gpu.org and libre-cpu.org, do we want to keep them or should I just let them expire? | 18:27 |
| lxo | no 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 name | 18:30 |
| lxo | can you imagine computers shipping with a happy-you inside? who wouldn't want one? :-) | 18:38 |
| programmerjake[m | lkcl any opinion on the domain names? | 18:38 |
| lxo | gonna miss tonight's virtual coffee :-( I'm already sleeping at the keyboard. sorry | 18:42 |
| programmerjake[m | well, sleep well, we'll miss you | 18:42 |
| lxo | programmerjake[m, I've refreshed the libre-soc branch in my gcc tree, btw. it probably has the patch you wanted | 18:42 |
| programmerjake[m | on the talos server or on git.libre-soc.org? | 18:43 |
| lxo | oh, yeah, I'm yet to push it to our git server. on the talos server only for now | 18:43 |
| lxo | I 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 testsuite | 18:45 |
| programmerjake[m | ah, ok | 18:46 |
| lxo | another 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 instead | 18:47 |
| programmerjake[m | well, I'll probably try and build it later today | 18:47 |
| lxo | stgiit makes it reasonably easy to manage a patchset as it evolves towards contributing it, but it doesn't quite retain the development history that way | 18:48 |
| programmerjake[m | since 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 history | 19:00 |
| lkcl | programmerjake[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-dest | 19:25 |
| lkcl | lxo: yes i understood "changing the opcode" to mean "change the mnemonic". | 19:26 |
| programmerjake[m | yup, I'm just doing some more advocating | 19:27 |
| programmerjake[m | :) | 19:28 |
| lkcl | :) | 19:29 |
| lkcl | the advantage of what you suggest does mean that this issue "goes away" | 19:29 |
| lkcl | hmm hmmm we're doing a hybrid cpu-gpu-vpu, the other domains would be misleading | 19:31 |
| programmerjake[m | while your here: lkcl any opinion on the ^ domain names? | 19:31 |
| programmerjake[m | or, is that what you just answered | 19:32 |
| programmerjake[m | i 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 |
| lkcl | the message sent by saying "it's a GPU" is unfortunately to say "it's incapable of being a CPU". | 19:36 |
| programmerjake[m | though that is changing .. the risc-v gpu project | 19:36 |
| lkcl | oh dear, they didn't. | 19:36 |
| programmerjake[m | yeah, ok | 19:36 |
| programmerjake[m | https://www.eetimes.com/rv64x-a-free-open-source-gpu-for-risc-v/ | 19:37 |
| lkcl | oh 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 |
| lkcl | yes, that one. it's literally 2 years out-of-date! | 19:37 |
| programmerjake[m | so, wait, they're not doing that anymore? | 19:38 |
| lkcl | he paid SiFive USD 75,000 to license their help and they screwed him over | 19:38 |
| lkcl | he was absolutely livid. that was his personal money. | 19:39 |
| programmerjake[m | well, that explains why they referred to Libre-RISC-V and not Libre-SOC | 19:39 |
| lkcl | he's since moved on to a more general-purpose concept, which he presented at siggraph 2020 | 19:39 |
| programmerjake[m | ah, ok | 19:40 |
| programmerjake[m | if you have any links it would be interesting reading, maybe send to libre-soc-misc | 19:41 |
| programmerjake[m | the siggraph thing | 19:41 |
| lkcl | https://www.pixilica.com/post/pixilica-s-founder-atif-zafar-to-give-a-talk-at-siggraph-2020 | 19:41 |
| lkcl | good idea, done | 19:42 |
| programmerjake[m | thx | 19:52 |
| lkcl | my friend david will be along tonight btw | 20:19 |
| lkcl | meeting | 21:58 |
| lkcl | programmerjake[m, ^ | 21:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!