| ghostmansd[m] | Also added svshape. | 00:38 |
|---|---|---|
| lkcl | ghostmansd[m], ah: sv.setvl does *not* exist. | 03:43 |
| lkcl | and it will never be added. | 03:43 |
| lkcl | setvl is *definitely* and *only* a 32-bit scalar instruction. there will *never* be a 64-bit instruction called "sv.setvl" | 03:44 |
| lkcl | yes, once one 32-bit instruction is added, new ones get real easy | 03:45 |
| littlebobeep | lkcl: Hi sorry if this is OT, but if you know about FPGAs...? Do you have an assessment on this project: https://github.com/enjoy-digital/litex vs. this: https://f4pga.org/ | 03:51 |
| littlebobeep | I am curious which I can use for a Xilinx Kintex-7 | 03:52 |
| littlebobeep | I don't know if this is realistic for running Libre-Soc?? | 03:52 |
| littlebobeep | I've never used an FPGA before so still coming to understand | 03:53 |
| lkcl | litex is fine for starting out, and as long as you do not want to make any modifications to what they provide it is fine. | 04:27 |
| lkcl | a deeper investigation into litex is where the problems start. | 04:28 |
| lkcl | prjxray says that experimentation has begun with kintex-7 | 04:29 |
| littlebobeep | lkcl: Do you know much about the problems with litex? | 08:05 |
| ghostmansd | lkcl, cf. these | 08:20 |
| ghostmansd | a usual sweet and simple setvl: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l191 | 08:20 |
| ghostmansd | ...and with the prefix yielded above: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l1083 | 08:20 |
| ghostmansd | same applies to many other insns, the code is identical | 08:20 |
| lkcl | ghostmansd[m], that's added as a *32-bit* instruction | 12:33 |
| lkcl | all of those instructions are added as 32-bit, because that's how SVP64 works | 12:33 |
| lkcl | you cannot have a "sv."-only instruction because SVP64 is a prefix system | 12:33 |
| lkcl | therefore | 12:34 |
| lkcl | the 32-bit instruction *has* to be added before the 64-bit prefixed variant can even be added | 12:34 |
| lkcl | BUT | 12:34 |
| lkcl | (and this is the important bit) | 12:34 |
| lkcl | setvl, svstep, svshape and svremap are *control* instructions, *NOT* Vector instructions. | 12:35 |
| lkcl | they *control* the Vector system, they are not themselves actually Vectorised. | 12:35 |
| lkcl | thus | 12:35 |
| lkcl | they must remain 32-bit only. | 12:35 |
| lkcl | there will never, under any circumstances, be: | 12:35 |
| lkcl | sv.setvl | 12:35 |
| lkcl | sv.svstep | 12:35 |
| lkcl | sv.svshape | 12:35 |
| lkcl | sv.svremap | 12:35 |
| lkcl | if anyone makes such instructions, they must be raised as illegal syntax errors | 12:36 |
| lkcl | the only reason i added them, like fsins (line 257) is precisely because the scalar binutils doesn't have them | 12:36 |
| lkcl | if the RM-NN-MM-OO.csv files actually contain setvl, svstep, svshape or svremap that's a major mistake | 12:37 |
| * lkcl checking | 12:38 | |
| lkcl | $ grep setvl * | 12:38 |
| lkcl | minor_22.csv:0b00000,VL,OP_SETVL,RA_OR_ZERO,NONE,NONE,RT_OR_ZERO,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,setvl,SVL,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 12:38 |
| lkcl | it's not in any of the RM-1P-1D.csv etc. so that's correct | 12:39 |
| lkcl | $ grep sv *.csv | 12:40 |
| lkcl | minor_22.csv:0b00001,VL,OP_SVSHAPE,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,svshape,SVM,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 12:40 |
| lkcl | minor_22.csv:0b00010,VL,OP_SVREMAP,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,svremap,SVRM,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 12:40 |
| lkcl | minor_22.csv:0b00011,VL,OP_SVSTEP,NONE,NONE,NONE,RT,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,svstep,SVL,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 12:40 |
| lkcl | RM-1P-1D.csv:svstep,NORMAL,,1P,EXTRA3,d:RT;d:CR0,0,0,0,0,0,0,RT,0,CR0,0 | 12:40 |
| lkcl | and likewise svstep, svremap, svstep - all *NOT* in the RM-NN-MM.csv files | 12:41 |
| lkcl | think of it this way: setvl sets the global (QTY 1) SVSTATE Special Purpose Register which controls the entire Vector system, setting how many elements there are | 12:41 |
| lkcl | "sv.setvl" would be: | 12:42 |
| lkcl | please set a Vector of Vectors of SVSTATE Special Purpose Registers, from 0 to VL-1 | 12:42 |
| lkcl | that's not going to work, is it? :) | 12:42 |
| lkcl | littlebobeep, the primary developer of litex was so spiteful and unethical i'd prefer not to talk about litex on this channel. he was that rude and caused immense problems, wasting a lot of my time in attempting to damage my reputation and that of this project | 12:49 |
| lkcl | ghostmansd[m], https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=0296c808691d0ccb68f05209c44504e0119ab703 | 15:20 |
| ghostmansd[m] | lkcl, what about this? | 15:21 |
| ghostmansd[m] | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l1109 | 15:21 |
| ghostmansd[m] | This is after splitting sv. prefix | 15:21 |
| ghostmansd[m] | First, we yield prefix: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l1063 | 15:22 |
| ghostmansd[m] | Then insn itself: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l1109 | 15:22 |
| ghostmansd[m] | Also, regarding sv.setvl... | 15:23 |
| ghostmansd[m] | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py#l1269 | 15:23 |
| ghostmansd[m] | This seems to check it, eh? | 15:23 |
| ghostmansd[m] | This is kinda confusing, because there should be no sv.setvl insn | 15:24 |
| ghostmansd[m] | But svp64.py considers it | 15:25 |
| lkcl | ghostmansd[m], again, those are there because, again, binutils does not support the assembler mnemonic "setvl" or "svstep". | 19:04 |
| ghostmansd[m] | Please correct me if I'm wrong | 19:05 |
| ghostmansd[m] | But | 19:05 |
| ghostmansd[m] | You handle _both_ sv.setvl and setvl | 19:05 |
| ghostmansd[m] | First, we check opcode | 19:05 |
| lkcl | tht code should never be reached | 19:05 |
| lkcl | i will delete it now to make it absolutely clear. | 19:06 |
| ghostmansd[m] | And how this should be guessed? | 19:06 |
| ghostmansd[m] | Yes, please do | 19:06 |
| ghostmansd[m] | Because, well, this looks kinda outdated | 19:06 |
| ghostmansd[m] | And this is the whole reason why I raised this topic :-) | 19:06 |
| ghostmansd[m] | I'd re-visit the whole svp64 once you have time | 19:08 |
| lkcl | ok, in *theory* it's possible, not because it's Vectorised | 19:08 |
| ghostmansd[m] | Because _you_ have the whole picture | 19:08 |
| ghostmansd[m] | But not _me_ | 19:08 |
| lkcl | but because of something called "Scalar Identity" | 19:09 |
| lkcl | the only valid circumstance where you could have "sv.setvl" is if there's absolutely no modifier flags whatsoever | 19:09 |
| lkcl | no sv.setvl/ew=xxx, no sv.setvl/sm=yyyy | 19:09 |
| lkcl | which is pointless and a waste of 24-bits of opcode space | 19:09 |
| lkcl | so it's something to reserve for later | 19:10 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=7351a6051e032234cb52a0833f3eb2262023a775 | 19:10 |
| ghostmansd[m] | Yes, but, still: after the code checks for sv. and remaps, it handles some insns specifically | 19:10 |
| ghostmansd[m] | So, you know, I had no other option but ask | 19:10 |
| ghostmansd[m] | Ok, seems clearer now :-) | 19:11 |
| ghostmansd[m] | But, still, I have no idea how it appeared for the first place | 19:12 |
| ghostmansd[m] | If this is bothering and stupid, just let me know | 19:12 |
| lkcl | cut/paste error? don't know | 19:12 |
| lkcl | no, it's important | 19:12 |
| lkcl | some things, like the disastrous ld-st-with-shift experiment, still haven't fully been cut out | 19:13 |
| ghostmansd[m] | I suggest to raise a standalone task with it's own budget to update svp64.py to current state of art. | 19:14 |
| ghostmansd[m] | Because this _is_ important. | 19:14 |
| ghostmansd[m] | Because, well, I've entered this stuff at somewhat outdated stage, you know | 19:15 |
| ghostmansd[m] | And, long before binutils are ready, we have the current solution, which _does_ work | 19:15 |
| ghostmansd[m] | And I'd really like this to be tied to current state of art | 19:16 |
| lkcl | yeah it's going to have to be integrated into unit tests as an option to use | 19:16 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!