programmerjake[m | lkcl: i think svp64 instructions without any vector arguments *should* be not dependent on VL==0 or not, they are used for purely scalar operations and are needed to access out-of-32-bit-range registers. | 00:11 |
---|---|---|
programmerjake[m | after all, svp64 != vector instruction | 00:11 |
lxo | programmerjake[m, that's my reasoning as well | 00:57 |
lxo | lkcl's reasoning makes sense as well, but I'll have to rethink how to implement scalar moves involving the extended svp registers | 00:59 |
lxo | since their behavior will be affected by VL, it will have to be another input operand of pretty much every instruction | 01:01 |
programmerjake[m | this is just the latest instance of the trap of "scalar is just vector element 0" -- scalar really *should be* a totally different kind of thing than vector | 01:07 |
programmerjake[m | and svp64 should not automatically mean vector | 01:08 |
programmerjake[m | I guess you can summarize what I envision for svp64 as: prefix for accessing stuff added with SV. one of the features is vector operation, another independent feature is accessing registers > r31, another one is predication, and so on. | 01:14 |
programmerjake[m | using svp64 doesn't automatically enable everything always, so why should vector/scalar be any different? | 01:15 |
programmerjake[m | or, at least svp64 shouldn't automatically enable everything, all it does is provide the instruction fields with which all the new features can be independently enabled | 01:17 |
lxo | programmerjake[m, or we could market svp64 as adding millions of new forms of nop ;-D | 01:41 |
programmerjake[m | but powerpc already has millions of nops...guess it never hurt anyone to add more :P | 01:42 |
programmerjake[m | kinda like x86 has all the nops from 1 to 15 bytes long | 01:42 |
lxo | make sv.nop generate a random svp64-prefixed insn, for better code obfuscation | 01:43 |
lxo | is setvli an svp64 insn, or is it not? | 01:45 |
lxo | as in, after setting vl=0, can setvli still have any effect, or do you have to reset the processor to get out of the sv.nop mode? | 01:47 |
programmerjake[m | setvl[i] would be a non-svp instruction, but now I'm wishing it was a svp instruction just to prove my point :P | 01:50 |
lxo | :-) | 02:21 |
lkcl_ | http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002114.html | 13:45 |
lkcl_ | cesar[m]2, yes scalar identity is identical... as long as VL=1. | 13:46 |
lkcl_ | there are going to be some permutations that quotes "do not make sense" quotes and there is nothing that can be done about that without also creating hardware-level decode dependencies that would absolutely kill the entire project stone dead | 13:47 |
lkcl_ | i added setvl to context-propagation https://libre-soc.org/openpower/sv/propagation/ | 15:47 |
lkcl_ | context-propagation is a second phase which should reduce the impact of prefixing | 15:48 |
lkcl_ | hilariously it's possible to also add the v3.1 64-bit prefixes to the same table | 15:48 |
lkcl_ | i am not sure if context-propagation of setvl info will actually result in reduction of executable size though. | 15:49 |
lkcl_ | have to see how that goes | 15:49 |
lkcl_ | lxo: setvl - of which setvli is a pseudo-op constructed from setvl - is a 32-bit only instruction. | 16:45 |
lkcl_ | vl=0 converting all vector operations to NOPs is exactly how RVV operates, exactly how Cray Supercomputers have always operated. | 16:47 |
programmerjake[m | one of the other reasons for wanting SVP64 scalar instructions is from a sense of math purity -- 1D tensors (ISA-level/compiler-level vectors) and scalars are 2 different kinds of math object, they should not be conflated. Also, having SVP64 scalars maps much more nicely to the compiler-IR-level, since that also has separate scalar and vector types. | 18:33 |
lxo | meeting in 10', right? | 20:50 |
lxo | I'm preparing to get thoroughly confused by DST changes in the Northern hemisphere :-) | 20:51 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!