| *** octavius <octavius!~octavius@214.147.93.209.dyn.plus.net> has quit IRC | 00:32 | |
| lkcl- | naah. that's "only" 25,000 intrinsics | 01:13 |
|---|---|---|
| lkcl- | the answer's no. | 01:13 |
| lkcl- | hard no. | 01:13 |
| lkcl- | SV is a 2-Dimensional ISA in effect: the prefix is separate from the suffix, and intrinsics should reflect that | 01:14 |
| lkcl- | it's the whole damn point. | 01:15 |
| programmerjake | well, sorry, llvm doesn't work that way...unless you want to spend many years rewriting major portions of it -- also i highly doubt they'd accept it upstream. imho what we need is to have intrinsics with const parameters, so we only need one generic intrinsic for each op such as add, sub, mul, etc. and the rest is determined by input/output types and const arguments | 01:25 |
| programmerjake | there's only 25-50 such ops (add, sub, mul, etc...) we'd need, because llvm ir is pretty simple. | 01:31 |
| programmerjake | that's not including all our specialty extensions, just svp64 and base powerisa | 01:32 |
| programmerjake | do note those ops won't match 1:1 to svp64, since some things work better in ir as separate ops that are fused in the backend, e.g. imho twin-predication should be built from separate register compress/expand ops and the underlying add/etc. op. | 01:35 |
| programmerjake | just like how powerisa's rotate and mask ops are expressed in llvm ir as separate shift, and, or, and rotate ops | 01:36 |
| programmerjake | also, where the svp64 intrinsics match existing intrinsics, the existing intrinsics should be used to take advantage of code already written using those intrinsics -- both frontends like clang and rustc and optimizations like loop autovectorization. | 01:39 |
| lkcl- | we're | 03:02 |
| lkcl- | not | 03:02 |
| lkcl- | doing | 03:03 |
| lkcl- | a | 03:03 |
| lkcl- | million | 03:03 |
| lkcl- | intrinsics | 03:03 |
| lkcl- | we're not limiting what svp64 can do either | 03:03 |
| lkcl- | fitting into a broken paradigm is a serious mistake. | 03:05 |
| lkcl- | the entire paradigm for llvm is to fit with SIMD (and now RVV). | 03:05 |
| lkcl- | they are based on 1D ISAs | 03:06 |
| lkcl- | SVP64 is a 2D ISA | 03:06 |
| lkcl- | the paradigms do not match and they're just going to have to suck it up. | 03:06 |
| lkcl- | any kind of compromise here basically means limiting SVP64 to 0.5% of its full capability | 03:07 |
| lkcl- | which is about as stupid as it gets. | 03:07 |
| lkcl- | it sends a message "we wasted 3+ years of our lives to design an ISA that we can't be bothered to state our case and assert ourselves in a reasonable and rational way why things should be done better" | 03:08 |
| lkcl- | i'm sorry but that's just not in the least bit acceptable | 03:08 |
| lkcl- | we've developed literally the most powerful ISA in the world | 03:09 |
| lkcl- | it was quite by accident, but that's no excuse | 03:09 |
| lkcl- | NO compromises. | 03:09 |
| lkcl- | if that means we have to raise USD 25 million to get the compiler done then we goddamn raise USD 25 million. | 03:10 |
| lkcl- | now, that said, there's a way to go about presenting a case for a different approach as reasonable people | 03:16 |
| lkcl- | and there's a way to do it as complete dickheads | 03:16 |
| lkcl- | the former's much more sensible | 03:17 |
| programmerjake | i said 25-50 generic intrinsics, not 1M | 03:17 |
| lkcl- | but if we go to them and say "we want to fit in with llvm's limited scalable vector intrinsics that were never designed with the full capability of svp64 in mind" | 03:18 |
| lkcl- | we're sending a message that svp64 is like all other 1D ISAs | 03:19 |
| lkcl- | that's a mistake that we'll never fully recover from | 03:19 |
| programmerjake | we're fitting in only where the svp64 op is identical, because backward compat is impprtant, otherwise it uses a svp64 intrinsic. | 03:19 |
| programmerjake | we don't want everyone who uses llvm to have to rewrite everything just to use svp64, when their existing code is perfectly sufficient and can be easily translated by llvm's backend | 03:20 |
| programmerjake | that's kinda like saying "i don't like c's for loop, i have a better replacement, so lets build a c compiler with only the replacement and not the original for loop and everyone can just rewrite all their c code to use the new for loop, all of debian, linux, and everything else written in c" | 03:23 |
| programmerjake | so that's why i want svp64 to use the existing intrinsics when possible | 03:24 |
| programmerjake | > we're sending a message that svp64 is like all other 1D ISAs | 03:28 |
| programmerjake | no, we're sending a message that existing 1D ISA's operations also work on svp64 -- which is true and a large part of why svp64 is better than rvv (which doesn't really support fixed-length ops) | 03:28 |
| lkcl- | hmm hmm, let me mull on it for a while | 04:06 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:30 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 06:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has joined #libre-soc | 06:45 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:03 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has quit IRC | 07:24 | |
| markos | tbh, it would be simpler even as an alternative to just fork llvm and work our own 2D intrinsics, and just send a PR when ready, and just try to be as non-intrusive as possible, llvm has been quite receptive in the past, probably more than gcc so I don't think it's unlikely | 07:31 |
| markos | ie, I would follow both paths | 07:32 |
| markos | a) short term just support the most common operations, b) long term, fork and design/implement a 2D intrinsics on a fork of llvm | 07:33 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:35 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:53 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.166> has joined #libre-soc | 08:08 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.166> has quit IRC | 08:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.186> has joined #libre-soc | 08:20 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.186> has quit IRC | 08:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:33 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:42 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 08:43 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 08:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:25 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.50> has joined #libre-soc | 09:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.50> has quit IRC | 10:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:31 | |
| *** octavius <octavius!~octavius@146.147.93.209.dyn.plus.net> has joined #libre-soc | 10:39 | |
| markos | coming to elaborate a bit more on what I suggest, the first plan is easy to implement and would probably take only a few months and should be only used an interim solution -keeping the same intrinsic names- while the 2nd is the proper long term goal, requiring much more work | 10:47 |
| markos | however it would still be nice to do, because it would help solve possible problems | 10:48 |
| markos | if I'd have to choose only one solution, I'd go for the 2nd | 10:48 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:52 | |
| ghostmansd | lkcl, I might have asked this already, but still. In RM-1P-1D.csv, what are the 1P-1D parts? I assume 1P/2P are sv_ptype; what does 1D mean? Perhaps I could re-use this stuff as a hint and put more checks there upon parsing it all. | 10:59 |
| lkcl- | 1P is 1 predicate, 2P is twin predicate | 11:36 |
| lkcl- | 1D means "1 destination" | 11:36 |
| lkcl- | 1s means "1 source" | 11:36 |
| lkcl- | that's either GPR, FPR, or CR. | 11:36 |
| lkcl- | (excluding Rc=1 which is implicit and always matches with the destination result) | 11:37 |
| lkcl- | so, "2S" means "there were a total of 2 source registers, they were GPRs, FPRs, or CR Fields" | 11:37 |
| lkcl- | in this way you can tell at a glance exactly how many registers there are | 11:38 |
| lkcl- | and therefore how many entries in the RM.EXTRA you have to fill in | 11:38 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_analysis.py;hb=HEAD#l643 | 11:38 |
| lkcl- | 643 elif value == 'RM-1P-2S1D': | 11:39 |
| lkcl- | that's only 3 registers (2 source + 1 dest) | 11:39 |
| lkcl- | therefore it can fit in EXTRA3 | 11:39 |
| lkcl- | 644 res['Etype'] = 'EXTRA3' # RM EXTRA3 type | 11:39 |
| lkcl- | so what about any instructions beginning "cr" such as "crand", "cror"? | 11:40 |
| lkcl- | 645 if insn_name.startswith('cr'): | 11:40 |
| lkcl- | 646 res['0'] = 'd:BT' # BT: Rdest1_EXTRA3 | 11:40 |
| lkcl- | 647 res['1'] = 's:BA' # BA: Rsrc1_EXTRA3 | 11:40 |
| lkcl- | 648 res['2'] = 's:BB' # BB: Rsrc2_EXTRA3 | 11:40 |
| lkcl- | let's make EXTRA3_0 the destination extension for BT | 11:40 |
| lkcl- | EXTRA3_1 cover the 1st source BA | 11:40 |
| lkcl- | and EXTRA3[2] cover the 2nd, BB | 11:40 |
| lkcl- | etc. | 11:41 |
| lkcl- | etc. | 11:41 |
| lkcl- | etc. | 11:41 |
| lkcl- | really quite boring and by-the-numbers-bloody-obvious | 11:41 |
| lkcl- | but if you don't have a "register profile" (total number of reg operands) you can't do that | 11:41 |
| lkcl- | hence | 11:41 |
| lkcl- | sv_analysis.py goes through the entirrre ISA looking for "register profiles" | 11:42 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 12:23 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 12:24 | |
| octavius | lkcl, are there any tasks you need assistance with? After friday afternoon I'll be heading off to orienteer in the Lake District, and will be away for a week. | 12:25 |
| octavius | The HiTas examples that seem to hang, haven't progressed after a few hours. So my intuition tells my there's something missing, but I didn't see errors or warning during the build process. | 12:25 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.229> has joined #libre-soc | 12:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.229> has quit IRC | 13:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:08 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 13:32 | |
| ghostmansd | lkcl, thanks for the explanation! | 13:56 |
| ghostmansd | also, another question on svp64 tables. We have sv_inX and sv_out entries. In CSV files, we have say addi,NORMAL,,2P,EXTRA3,d:RT,s:RA,0,0,RA_OR_ZERO,0,0,RT,0,0,1,0 record, where sv_in1is RA_OR_ZERO. However, the resulting sv_in1 in get_svp64_csv won't be RA_OR_ZERO, but it would be one of SVEXTRA, right? | 13:59 |
| ghostmansd | Ah yeah, found it: # now examine in1/2/3/out, create sv_in1/2/3/out | 14:00 |
| ghostmansd | Having 0,1,2,3 and in1,in2,in3,out fields is controversial, I'd say :-) | 14:03 |
| ghostmansd | As I understand, we don't really use these per se, but, rather, call decode_extra on them and then convert this all to sv_in1 et al., right? | 14:03 |
| lkcl- | octavius, the pinmux - joining the Mux-GPIO class you wrote, with the json-reader-class ineptly named "Pins", is your next mission :) | 14:12 |
| octavius | Thanks! | 14:12 |
| lkcl- | octavius, ok we wait for Marie-Minerve to come back from holiday | 14:12 |
| octavius | also, fvmw is very cool (prepping my spare laptop with IRC to take with me) | 14:13 |
| lkcl- | ghostmansd, i think the 0,1,2,3 if i recall correctly, refers to the EXTRA indexing | 14:13 |
| lkcl- | it... i remember melting my brain on how that actually works. | 14:14 |
| ghostmansd | These can be like d:RT or similar | 14:14 |
| ghostmansd | They're used by decode_extra. | 14:15 |
| lkcl- | i remember it being complicated. i'm in the middle of something (mentally) so you'll have to excuse me, i can't cope with flipping between one complex topic and another just as complex | 14:15 |
| ghostmansd | Sure :-) | 14:15 |
| ghostmansd | np | 14:15 |
| ghostmansd | I think I already found the answer, anyway | 14:16 |
| lkcl- | but, did you get the idea of putting bitsel into the actual CSV file as a comment? | 14:16 |
| lkcl- | the important bit about that idea is that it tells you that the bitsel applies to the *entire* CSV file | 14:16 |
| lkcl- | i did explain this but you likely missed it | 14:16 |
| ghostmansd | Nope, I didn't miss it :-) | 14:16 |
| lkcl- | i said that in create_pdecode, the *parent* has the bitsel which applies to its *child* list of Subdecoders() | 14:17 |
| ghostmansd | I'm not sure whether we should put it as comment, I'd rather preferred having some standalone file which has this mapping | 14:17 |
| lkcl- | if you can add bitsel to the... mmmm yuk | 14:17 |
| lkcl- | okaay. | 14:17 |
| lkcl- | yeah that kinda works | 14:17 |
| ghostmansd | Even hardcoding it in the code is better... | 14:17 |
| ghostmansd | Because, well, comments are comments | 14:17 |
| lkcl- | i kinda like the information being directly at the point it's used | 14:18 |
| ghostmansd | There are exceptions like shebang, though | 14:18 |
| ghostmansd | Yeah, me too... The only thing which prevents it is the CSV format | 14:18 |
| ghostmansd | Because it's somewhat limited | 14:18 |
| ghostmansd | And putting anything that doesn't fit it in comments is not a silver bullet either | 14:18 |
| ghostmansd | Right now I'm re-thinking basic structures around CSVs so that all stuff is typed properly (e.g. Ptype field comes out of CSV parser as power_enums.SVPtype, and so on). | 14:20 |
| lkcl- | as you probably noticed i have a pretty direct "get-it-done-y'all" attitude to certain types of programming problems | 14:21 |
| lkcl- | it leads to surprisingly compact code, when compared to "The Nice Way With Classes n Stuff" | 14:22 |
| lkcl- | but is horrendous to understand, later | 14:22 |
| ghostmansd | both approaches have the right to exist :-) | 14:26 |
| ghostmansd | I actually use both, the "nice way with classes" preferably when there's a need to refactor the code (e.g. when it has to be used by more than 1 subsystem) | 14:26 |
| lkcl- | yehyeh no makes perfect sense | 14:27 |
| lkcl- | octavius, do print out that PDF and actually put it in the post to FundingBox | 14:30 |
| lkcl- | toshywoshy, same | 14:31 |
| lkcl- | just remember to scan the words for that missing "NOT" in the legally-binding declarations | 14:31 |
| octavius | Ah yes, lkcl, will do. Writing that Polish address is going to be fun XD | 14:40 |
| lkcl- | if you can, send it Recorded Delivery then send a copy of the receipt to Marie | 14:41 |
| lkcl- | it will get held up in customs but we dont' care, it's the "proof-of-posting" that's important | 14:42 |
| octavius | Sure, no prob | 14:42 |
| lkcl- | toshywoshy, you got ACKs on the 2 grants? 2 is a good idea https://libre-soc.org/nlnet_2022_librebmc/ | 14:47 |
| toshywoshy | yes, I got submission ids, I did not get any mail confirmation yet, they tend to come in very late | 14:49 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.235> has joined #libre-soc | 16:04 | |
| lkcl- | yes, 3 days late | 16:15 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.235> has quit IRC | 16:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 17:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 17:17 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.80> has joined #libre-soc | 17:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.80> has quit IRC | 17:32 | |
| *** octavius <octavius!~octavius@146.147.93.209.dyn.plus.net> has quit IRC | 17:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:41 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:04 | |
| ghostmansd | lkcl, any tips on what PU can be? From the sources it seems it can be either 1 or be omitted. Should I consider a boolean value? | 20:05 |
| ghostmansd | Also, speaking of SVP64 CSVs (not "vanilla" ones). What mode could be? | 20:22 |
| ghostmansd | insn,mode,CONDITIONS,Ptype,Etype,0,1,2,3,in1,in2,in3,out,CR in,CR out,PU,out2 | 20:22 |
| ghostmansd | From the code, it seems that it can be NORMAL, LDST, BRANCH or CROP... | 20:23 |
| ghostmansd | Is it correct? I'm thinking of adding yet another enum to establish it once and forever, and have the corresponding checks. | 20:24 |
| ghostmansd | Ah yeah, right, https://libre-soc.org/openpower/sv/svp64/ has Mode section. | 20:26 |
| programmerjake | lkcl, afaict i found a bug: both if and else set pack to 1: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_analysis.py;hb=b1efd05e410dd33888967b6dfe9a618f6b480f27#l492 | 20:27 |
| lkcl- | programmerjake, ahh magic, i hadn't actually written any unit tests yet | 20:30 |
| lkcl- | ghostmansd, there's two flags, pack and unpack. they can *both* be set. | 20:30 |
| lkcl- | i wrote some assembler options err... yesterday? | 20:30 |
| ghostmansd | I'm just looking at CSVs, don't really think of asm now :-) | 20:31 |
| lkcl- | fouund iiit https://libre-soc.org/irclog/%23libre-soc.2022-07-30.log.html#t2022-07-30T05:29:49 | 20:31 |
| lkcl- | the way it works is: | 20:32 |
| lkcl- | there is vector loops 0..vl-1 | 20:32 |
| lkcl- | and there is subvector loops 0..subvl-1 | 20:32 |
| lkcl- | there is also source-looping and there is dest-looping | 20:32 |
| lkcl- | the "normal" way you do element-walking is | 20:33 |
| lkcl- | for i in range(VL): for j in range(SUBVL): index = (i*SUBVL)+j | 20:33 |
| lkcl- | where if SUBVL=1 then obviously that degenerates to just a VL loop | 20:33 |
| lkcl- | Pack will *invert* the application of the for-loops for *source* index walking | 20:34 |
| lkcl- | Unpack invert the application of the for-loops for *destination* index walking | 20:34 |
| programmerjake | pack/unpack will definitely be useful for 3D stuff, i was planning on just using several strided load/stores for that | 20:34 |
| lkcl- | it's freaky as hell :) | 20:34 |
| lkcl- | yeah, 3D and RGB/ARBG or YUV pixels in video. | 20:35 |
| lkcl- | because you can pack/unpack all the R R R R separate from G G G G and B B B B | 20:35 |
| * lkcl- (explaining to ghostmansd, programmerjake) | 20:35 | |
| ghostmansd | OK, so basically PU indicates whether insn supports /vp /pu /vu /pu, right? | 20:36 |
| ghostmansd | I mean PU field in CSV | 20:36 |
| lkcl- | "/vp" for pack and "/vu" for unpack and "/pu" for both flags | 20:36 |
| lkcl- | yes, freakily, both flags being set is perfectly valid | 20:37 |
| lkcl- | there's only 3 settings because the default is "don't raise either flag" | 20:37 |
| lkcl- | no point wasting asm-space raising default settings | 20:38 |
| ghostmansd | OK, I understand that in insn encoding, we can set PACK_en or UNPACK_en or even both. | 20:38 |
| lkcl- | yes. | 20:38 |
| ghostmansd | But what about CSV field? | 20:38 |
| lkcl- | now | 20:38 |
| lkcl- | here's the weird bit | 20:38 |
| programmerjake | just saw: https://www.phoronix.com/news/Linux-6.0-SPI-Better-Perf | 20:39 |
| lkcl- | based on how you've designed sv_binutils, you *should* just be able to re-run it and laugh manically at how easy it was to adapt to the new LDST-2P-1S1D-PU format | 20:39 |
| programmerjake | better linux SPI performance might be useful for us | 20:39 |
| lkcl- | as in: the *only* thing you should actually need to do is add the "/pu" "/vp" and "/vu" flags support. | 20:40 |
| ghostmansd | binutils are not an issue, they don't even consider fields they don't know how to deal with yet | 20:41 |
| ghostmansd | I'm raising these questions due to 838 and 835 | 20:41 |
| lkcl- | yes, exactly, and the changes from EXTRA3 to EXTRA2 are... ahhh | 20:41 |
| *** octavius <octavius!~octavius@146.147.93.209.dyn.plus.net> has joined #libre-soc | 20:41 | |
| lkcl- | honestly i'm not so bothered by the csv files containing "comments that happen to mean stuff" | 20:45 |
| lkcl- | however a comment saying "the next line means stuff, don't alter it" is probably a good idea :) | 20:46 |
| lkcl- | or even if you think it a good idea to put the contents into another CSV file it would be best to have comments in that, as well | 20:46 |
| lkcl- | eh what the heck. bitsel.csv | 20:46 |
| ghostmansd | yes, I'm thinking of keeping such information in separate file | 20:46 |
| ghostmansd | by the way, CSVs suck :-) | 20:47 |
| ghostmansd | the only reason I'm considering them now is because they're simple | 20:47 |
| ghostmansd | that's as long as the stuff is simple, obviously | 20:48 |
| ghostmansd | and also for a least astonishment: if all the data is in CSV, why should bitsel be somewhere else, eh? | 20:48 |
| lkcl- | yyep, and they're ubiquitous. | 20:48 |
| lkcl- | true :) | 20:48 |
| lkcl- | i think it sensible to hit all the minor_xxx.csv files with a comment saying "bitsel.csv says what column 0 means" | 20:50 |
| programmerjake | imho we should use something like json5 -- json with comments and allowing trailing comments and not requiring quotes for object keys...last time we discussed it we took the easy route of adding comments to the csv instead | 20:50 |
| programmerjake | trailing commas* | 20:51 |
| lkcl- | latest-and-greatest terminates all and any possibility of older systems from being able to read the data. | 20:56 |
| lkcl- | this is... not a good attitude to take towards data that is intended to be accessible as a specification | 20:57 |
| lkcl- | csv files can be read by sed, awk, bash, and simple perl scripts | 20:58 |
| ghostmansd | they only cannot be read by humans :-) | 21:00 |
| ghostmansd | sorry, could not resist | 21:00 |
| ghostmansd | I don't recall the exact quote, but, kinda like... | 21:03 |
| programmerjake | iirc jq can easily be used, it's commonly available on linux systems | 21:05 |
| programmerjake | it's kinda like awk, but for json | 21:06 |
| ghostmansd | There are languages which are designed to be machine-readable. There are languages which are designed to be human-readable. XML fits neither of these niches. | 21:07 |
| ghostmansd | I don't recall the quote, perhaps even the language chosen was different, but you get the spirit :-) | 21:08 |
| programmerjake | json fits both, but better as machine readable. csv is nearly totally non-human readable because you have to go to great lengths to figure out which column your in. | 21:09 |
| programmerjake | imho sed/awk compatibility is less important than being human readable, jq is a sufficient replacement | 21:10 |
| ghostmansd | Well it's possible if you have a good editor | 21:11 |
| programmerjake | yes, so is raw binary... | 21:11 |
| ghostmansd | Jokes aside | 21:11 |
| ghostmansd | stdux,LDST,,2P,EXTRA2,d:RA,s:RSs:RA,s:RB,0,RA_OR_ZERO,RB,RS,0,0,0,1,RA | 21:11 |
| ghostmansd | s:RSs:RA | 21:11 |
| ghostmansd | This looks like a broken entry; I'd have expected s:RS;s:RA | 21:12 |
| ghostmansd | openpower/isatables/LDSTRM-2P-2S1D.csv | 21:12 |
| ghostmansd | other entries below stdux too | 21:13 |
| ghostmansd | Also, s:CR doesn't look like a valid entry, too; s:CR0 does, as well as s:CR1. Please correct me if I'm wrong. | 21:15 |
| programmerjake | which table? mtcr stores to the whole CR reg so s:CR would be correct afaict | 21:17 |
| programmerjake | still in openpower/isatables/LDSTRM-2P-2S1D.csv? | 21:17 |
| ghostmansd | mfcr/mfocrf,NORMAL,,2P,EXTRA3,d:RT,s:CR,0,0,0,0,0,RT,WHOLE_REG,0,1,0 | 21:18 |
| ghostmansd | openpower/isatables/RM-2P-1S1D.csv | 21:18 |
| ghostmansd | openpower/isatables/RM-2P-2S1D.csv | 21:18 |
| programmerjake | ah, that's correct -- it reads the whole CR reg -- CR0-7 | 21:18 |
| ghostmansd | two tables which have such records | 21:18 |
| ghostmansd | OK, there's a need to support one more entry in enum then :-) | 21:19 |
| ghostmansd | Thanks programmerjake | 21:19 |
| programmerjake | idk if we want to support sv prefixed mfcr...seems not very useful | 21:20 |
| programmerjake | iirc lkcl decided to support it anyway | 21:21 |
| ghostmansd | lol seriously? | 21:28 |
| ghostmansd | OrderedDict([('insn', 'fishmv'), ('mode', 'NORMAL'), ('CONDITIONS', ''), ('Ptype', '2P'), ('Etype', 'EXTRA3'), ('0', 'TODO'), ('1', '0'), ('2', '0'), ('3', '0'), ('in1', 'FRS'), ('in2', 'NONE'), ('in3', 'NONE'), ('out', 'FRS'), ('CR in', 'NONE'), ('CR out', 'NONE'), ('PU', '1'), ('out2', 'NONE')]) | 21:28 |
| ghostmansd | I'm struggling to understand how I'm expected to handle TODO? :-) | 21:29 |
| ghostmansd | the fact that the current code _works_ is rather alarming | 21:31 |
| programmerjake | hmm, treat that as polling git until the TODO disappears :) | 21:31 |
| ghostmansd | :-D | 21:33 |
| *** octavius <octavius!~octavius@146.147.93.209.dyn.plus.net> has quit IRC | 22:04 | |
| *** octavius <octavius!~octavius@146.147.93.209.dyn.plus.net> has joined #libre-soc | 22:04 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!