Monday, 2022-09-12

*** lkcl <lkcl!> has joined #libre-soc00:24
*** octavius <octavius!> has quit IRC00:48
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC01:04
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:04
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC03:20
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:19
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:55
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC05:19
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:19
*** ghostmansd <ghostmansd!> has joined #libre-soc08:09
*** ghostmansd <ghostmansd!> has quit IRC08:34
programmerjakeopenpower-isa failed in CI:08:34
programmerjake  File "/builds/Kazan-team/mirrors/openpower-isa/src/openpower/sv/", line 181, in tformat08:34
programmerjake    return "| " + ' | '.join(d) + " |"08:34
programmerjakeTypeError: sequence item 3: expected str instance, NoneType found08:35
programmerjakemake: *** [Makefile:14: svanalysis] Error 108:35
programmerjakeafaict that error blocks me working on fptrans, since if i can't run svanalysis, i can't run tests after modifying csvs and adding pseudocode08:37
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:40
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc09:01
*** toshywoshy <toshywoshy!> has quit IRC09:05
*** toshywoshy <toshywoshy!> has joined #libre-soc09:05
*** openpowerbot <openpowerbot!> has quit IRC09:06
programmerjakebisected to
*** toshywoshy <toshywoshy!> has quit IRC09:10
*** toshywoshy <toshywoshy!> has joined #libre-soc09:10
*** openpowerbot <openpowerbot!> has joined #libre-soc09:11
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC09:19
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC09:19
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC09:19
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC09:19
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC09:19
*** ghostmansd <ghostmansd!> has joined #libre-soc09:25
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc09:26
programmerjakelkcl: svanalysis needs additional fixing because it miscategorizes the arguments for addpcis09:30
programmerjakebut at least it won't block my working on fptrans anymorr09:30
ghostmansdsuch a nice and readable format they said09:46
ghostmansdmissing comma: RAGE MODE ACTIVATED09:47
programmerjake^ most of why i want to rewrite the pseudocode parser, because it's also like that09:50
programmerjakeand not very understandable code due to the number of bodges09:51
programmerjakeoh, well, later09:51
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc10:01
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc10:01
*** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc10:01
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc10:01
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc10:02
lkclthat's addpcis not having a known-format10:47
lkcladded yesterday10:47
lkclwhat fun!10:48
lkclboth false objections, sorry folks.  you miss a "}" in json format or a dictionary-entry it's exactly the same thing11:30
lkcland no jacob rewriting the compiler because you don't understand it isn't a good reason to justify rewriting it11:30
lkclthe working-knowledge is in *my* head, and if you rewrite it then the working-knowledge becomes in *your* head, and the programming style that you deploy is so problematic and unreadable to me that it would be a catastrophic mistake11:31
programmerjakeuuh, you haven't seen my parser programming style before iirc...11:32
programmerjakealso, if it did a good job parsing, it would report an error pointing to the line/col in the csv or pseudocode where the error is and have a decent error message. currently it just fails with random python exceptions or just outputs bad data and you have to know/figure out exactly how the parser/simulator works to be able to guess where the error is11:35
lkclit does not matter what the style is, it's the very fact that it's different code that means it adds weeks onto *my* learning, risking jeapordising deadlines11:35
lkclworse than that it stops *you* from doing other much higher priority work11:36
lkclthis is about time and resource management11:36
lkclthe "kwahlliti" of the Kode can go f*** itself when time and resource management is concerned11:36
lkclthis is a practical pragmatic issue that you very much need to take on-board.11:37
lkclevery piece of work has to be thought of in terms of "where we are now, who understands what"11:37
programmerjakewell, the very fact that it has no decent error reporting makes adding new instructions take 2-3x as long because when the inevitable bug gets written it won't tell you where the bug is, making debugging take 5-10x as long11:37
lkclthe actual lines of code is actually completely unimportant11:38
lkcli don't have a problem with it.11:38
lkcli've *accepted* the limitations and compensated for it11:38
lkclusing exactly the same techniques that you say "take longer"11:38
lkcli don't complain about those techniques (putting debug print statements into the compiled output, cutting out lines of pseudocode until the error goes away)11:39
lkcli just get on with it11:39
lkclbottom line stop grumbling and suck it up! :)11:39
lkclwhen we have USD 40 million these things can be solved11:40
programmerjakewell, by choosing to have very little error checking you've effectively made it waay harder for anyone but you to contribute11:40
programmerjakeif we added up all the extra time people need to debug pseudocode in just the last year, it probably comes out to enough time to do a decent job rewriting the parser, which is an easier job for me than you think, because i have extensive experience writing parsers and type checkers11:44
programmerjakei've written at least 15 toy programming languages in the past, and several fully fledged ones11:44
programmerjakeanyway, we already decided to not do that now, so we can talk about it more later rather than now11:46
lkcldude: i find it *just as difficult*, the difference is, i *don't complain about it*11:57
lkcli just suck it up and get on with it11:57
lkclghostmansd, clearly this is you
ghostmansdno actually I stand on the same position for now, due to time constraints12:11
programmerjakethe view counter on that...26,263,636,336 .. seriously, 26 billion?!12:11
ghostmansdI don't like CSV and find it disgusting, but I understand the limitations12:11
lkcland now for something completely different
ghostmansdso that's why this "database" is not a database at all12:12
ghostmansdbut, rather, putting all stuff we have now under the same roof12:12
ghostmansd(I obviously fixed and changed some stuff, but basically it is what it is)12:12
lkclbtw someone from IBM is also doing the same thing12:12
lkcl(a "database" machine-readable version of the spec)12:13
ghostmansdWell, practically speaking, we're safe to assume anybody now thinks of doing it (if not doing yet).12:14
markosI agree that instead of CSV, we should just use a dictionary, key-value store, associative array, map, whatever you want to call it, something that is machine parsable and with some error checking, the end format doesn't matter, could be json/yaml or whatever12:16
markoseven sqlite would be better12:16
* lkcl screams12:16
markoshaving to edit CSV by hand is very suboptimal12:17
markosit's much easier to add a record with key=value instead of counting commas in a CSV, I know I made many mistakes while doing fmvis and it was only one instruction12:18
markoswell, ok, ignore sqlite :-P12:18
markosbut I also understand that it's not a discussion for now12:19
markoslkcl, I was reading about a "new" language, supposedly C/C++ compatible but with some nice features12:20
ghostmansdyes, I also checked it12:20
markos"Zig supports any comptime-known vector length up to 2^32-1, although small powers of two (2-64) are most typical."12:20
ghostmansdlkcl, by the way, how you do messages like "lkcl screams"?12:21
ghostmansdthey are highlighted differently12:21
markosjust write /me <text>12:21
* ghostmansd tries12:21
* markos claps12:21
* ghostmansd is a king of IRC now!12:21
ghostmansdCool. Cool cool cool.12:22
markosit's only 30 years old tech, but sure :D12:22
ghostmansdfrankly to me IRC is, well, like ICQ12:23
ghostmansd(does anybody uses it still?)12:23
markoshahaha, another bleeding edge tech12:24
markoshaven't used ICQ in over a decade12:24
ghostmansdone of Russian companies owns it now!12:24
markosand was one of the first adopters12:24
programmerjakei'm somewhat familiar with zig, imho they have cross compile support that's the envy of most other native languages, they made it so you can target any version of glibc you choose, compiling from any host arch/os, no special chroot needed12:24
ghostmansdI liked the compile-time tricks12:25
ghostmansdBut I haven't used it, just read about it12:25
markosreg. Zig, I was thinking of checking it out, it seems easier to develop for, and has a smaller learning curve, the drop-in compatibility of C/C++ is also a major bonus12:25
markossmaller than Rust that is12:25
ghostmansdThe site literally starts with ICQ -- the evolution of communication12:25
programmerjakeimho rust is better because it's more mainstream and is actually proven safe, zig is more like c/c++ in terms of memory safety12:26
ghostmansdForget Rust, forget Zig. Let's persuade lkcl to migrate to ICQ.12:26
markosI think Rust will never replace C/C++ in that regard, complement yes, replace no12:26
ghostmansdWe want to be on the bleeding edge!12:26
markosso there is definitely a place for new languages that want to improve C/C++ code12:27
programmerjakerust's cross-compile support is very good, but not up to zig's level12:27
markoseven Google rolled out their own language for that matter, Carbon iirc12:27
markoswhich also looks similar to Zig12:27
markosthe problem is that C/C++ codebase is absolutely enormous12:27
programmerjakegoogle, on carbon's page (paraphrasing): if you need c++ interop, use carbon, otherwise use rust12:28
markosmuch easier to incrementally improve this codebase with a better compiler that doesn't require total rewrite12:28
markoswell ofc I wouldn't expect Google to advocate eg. Zig :)12:28
ghostmansdnow you fundamentally eliminated one of the reasons Rust exists: to rewrite stuff for no other reason than doing it in Rust :-)12:29
programmerjakein particular, rust is still better even if you need c (but not c++) interop12:29
markosif I was 20y old and starting now in CS, I would probably learn Rust12:29
markosbut right now this is out of the question for me, there is just no time12:30
ghostmansdSeriously, this is one of the major reasons I hear on a regular basis about Rust. This is so brain-fucked, they even had RIIR -- rewrite it in Rust.12:30
ghostmansdPerhaps even have now.12:30
markosif it was a small codebase sure12:30
ghostmansdI cannot look at it with a serious face.12:30
markosbut try doing that with >1M SLOC of C/C++12:30
ghostmansdRewriting just for the mere fact of rewriting? No thanks.12:30
markosit would take years and even then the benefits would be small12:31
programmerjakerewriting for better memory safety and better abstractions, enabling higher performance due to better algorithms/datastructures enabled by better abstractions12:32
markosit would never be faster than C/C++, safer yes, faster no, but then again, with good tools, you can make a C/C++ almost 100% safe in much less time than it would take to rewriting it12:32
markosI honestly disagree there, the same algorithms can be implemented in whatever language you choose12:32
markoswell, obviously I'm not comparing python to Rust/C here12:33
programmerjakewell, if you try to use c++ hashtable and compare with rust's hashtable, rust wins in most cases because it uses a better datastructure that's prohibited by c++'s spec.12:33
ghostmansd> rewriting for better memory safety and better abstractions, enabling higher performance due to better algorithms/datastructures enabled by better abstractions12:33
ghostmansdYehyeh, the same old incantation12:33
programmerjakedoesn't mean it's false...12:34
markosprogrammerjake, if you're talking about STL, perhaps, but C++ has a ton of fast hashtable projects out there12:34
markosand it's usually just a case of adding an #include12:34
ghostmansdnah, I'd reserve Rust for some whistles and bells12:34
ghostmansdpet project -- perhaps12:34
ghostmansdnothing serious though12:35
programmerjakethe issue with c/c++ is it makes using better datastructures quite hard, especially for c, rust tends to make it pretty easy12:35
ghostmansdsame for zig, even though it looks way better and has less hype around by order of magnitude12:35
markosC enables some serious low level bitbanging tricks that are just impossible anywhere else, which is one of its strengths12:36
ghostmansd...and now the incantation about unsafe12:36
markosit's not about serious vs pet project, for me it's about codesize12:36
programmerjakeuuh, you can do all the bitbanging tricks in rust too, in fact some of them are easier because C has tbaa which makes some of those tricks UB, rust doesn't12:37
programmerjakee.g. loading a file into memory and reinterpreting as a struct12:37
markoswhich is one its strengths, exactly12:38
markosanyway, I only wanted to mention Zig as it had unlimited vector sizes by default, which might be interesting for SVP64, am not really after a Zig vs C/C++ vs Rust argument12:41
programmerjakealso rust has built-in access to a bunch of handy bitbanging-style functions that c needs compiler extensions or custom user implementations for: count leading bits, byte swap, float/int reinterpreting, reverse bits, wrapping signed arithmetic, etc.12:42
programmerjakebitwise rotate12:42
markosthese are all trivial to implement in C and have already been optimized since ages, it's not entirely a novelty12:43
programmerjakerust has limited vector sizes currently only because llvm fails for unusual sizes, the plan is to allow any reasonable vector length in the future, e.g. not 7 billion elements, but you can count on every integer from 1 to >64 being enabled12:45
markosfor Rust, I'd be already convinced by the memory safety alone, all the rest is not so important, because it's stuff you can find in standard headers/library or things like eg. boost12:45
markosonly thing that puts me away is the syntx12:46
markoswhen you write code in C/C++ for 30 years, Rust feels really weird12:46
markoswell for me at least12:47
programmerjakeimho one of the other major benefits of rust that's often overlooked is the type system, it allows you to add custom behavior to any type via writing new traits12:47
programmerjakeand it's kinda-sorta like c++ templates except implementations are checked when they're written, rather than when they're used, makes giant template backtraces nearly nonexistant12:50
programmerjakeand it doesn't have c++'s SFINAE nonsense12:52
markosC++ templates used to bother me, now I won't even think of writing performance critical code in C++ without them, they're not perfect, but I have yet to see something that works better, perhaps Rust traits are better as you say, but we again reach the same point, I cannot just migrate a large codebase to Rust because of 1-2 features, it would take years12:55
markosnow if someone decided to fund such a project, that would be a different matter12:56
markoseg. port vectorscan to Rust, would definitely take at least 12 months, probably more, quite likely the end codebase would be 1/3rd of the original, faster, safer and long-term proof than the current C++ codebase12:58
markosbut I wouldn't do it just because Rust is better12:58
markoshowever, I might decide in the future to attempt port to eg. Zig as it's more incremental and I could just play with a very small portion of the code and see how it works12:59
programmerjakeif you want to port a small part of a c++ codebase to rust to try it out, look at
markosinteresting, thanks for the link13:03
programmerjakeif you want more traditional c ffi, checkout bindgen and cbindgen, they translate c headers to rust and rust to c headers13:04
*** ghostmansd <ghostmansd!> has quit IRC13:41
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC14:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:18
lkclghostmansd[m], poke, poke: "setvl." isn't reconstructed ( - committing in 1 sec...15:29
lkclbut add add. addo addo. do.  huhn.15:31
ghostmansd[m]I don't get, Rc isn't constructed?15:32
lkclRc=1 is not picked up by pysvp64dis.15:33
lkclthe "." is not placed onto the end of the word "setvl"15:33
lkclwhere it is for "add."15:33
ghostmansd[m]. is not to be added by dis15:34
lkcl.... ahh.... err...15:34
ghostmansd[m]Do we have setvl. (Rc=1)?15:34
ghostmansd[m]In mdwn?15:34
ghostmansd[m]Other instructions do15:34
lkcl* setvl RT,RA,SVi,vf,vs,ms15:34
lkcl* setvl. RT,RA,SVi,vf,vs,ms15:34
ghostmansd[m]With (Rc=1)?15:34
ghostmansd[m]If not — these are same15:35
lkclerr... ah!15:35
ghostmansd[m]You forgot to differ these15:35
lkclah ha!15:35
lkclgot it15:35
ghostmansd[m]Rc=0, Rc=115:35
lkclah _ha_ :)15:35
lkclbleh that now became  : instruction does not match '.long 0x58a409b7' expected 'setvl. 5,4,5,0,1,115:36
lkclbut hey :)15:36
ghostmansd[m]Fields.text lacks Rc?15:36
ghostmansd[m]As a guess15:36
* lkcl checking15:36
ghostmansd[m]I'm AFK so cannot tell for sure15:36
lkclhmm it's there. Rc=1 SVL-Form15:37
lkcl    Rc (31)15:37
lkcl        RECORD bit.15:37
lkcl        Formats: A, M, MD, MDS, VA2, X, XFL, XO, XS, Z22, Z23, SVL, XB, TLI15:37
lkclhuhn?? o dear. if only one instruction then it works15:39
lkclcomment-out the other instructions in the test15:39
lkclo dearie me15:39
ghostmansd[m]I think it has to do with name matching15:40
lkcli do hate it when that happens15:40
ghostmansd[m]Check around exact_match et al.15:40
lkclwhat i'll do is just split these for now into separate tests.15:40
lkcli need to deal with something else15:40
ghostmansd[m]There is some func which looks for l on the end.15:40
ghostmansd[m]The crappiest part of the code perhaps.15:40
ghostmansd[m]>  i need to deal with something else15:41
ghostmansd[m]Hopefully remap for Idx_1_2? :-D15:41
*** octavius <octavius!> has joined #libre-soc15:45
lkclurrrr they're both RA_OR_ZERO and RT_OR_ZERO, urrrr15:46
lkclferrr... urrr15:46
lkclha ha very funny, sv_analysis marked the regtypes of sv.setvl as "TODO". most droll15:48
programmerjakeimho sv.setvl should be reserved for when we come up with schemes for extending the regfile15:50
programmerjakeok, please leave at least 3-4 bits reserved explicitly for extending the reg file, this was in 32-bit setvl but removed probably because it wasn't explicitly marked15:52
programmerjakethose bits allow selecting different extended regfile modes, tbd15:53
lkcli'm not even going to do anything other than hack this.15:53
lkclfor now15:53
lkcli'm overloading the "normal" encoding15:53
lkclthe task of creating yet another RM mode-format i'm not even going to look at15:53
lkclthe focus right now is to get Pack/Unpack completed15:54
programmerjakethough now that we have the new prefixed opcodes in the rfc you just submitted, we could just add a setvl2 that has a new field for extended stuff.15:55
lkcltakes up another precious 32-bit 5/6-bit XO15:55
programmerjake^ when we add extended regfiles, not now15:55
lkclbut those are only 32-bit encodings within a 64-bit space15:55
lkclwe need an excuse to justify setvl going into EXT000-063 and it being an SVP64-prefixable one makes that possible15:56
lkclif it isn't then the ISA WG could reasonably argue that setvl *only* go into the new 64-bit space15:56
programmerjakethe prefix has a bunch of bits that can be used for encoding new fields, like v3.1's prefix15:57
lkclwhich would have the rather disastrous consequences of punishing absolutely every single cray-vector algorithm15:57
lkclno it doesn't, that's the point.15:57
programmerjakereason to have 32-bit setvl: it's a common op15:57
lkcl(except if you define a new RM Mode)15:57
lkclyes. you and i know that15:58
lkclthe ISA WG might be convinced of that15:58
lkclbut the compiler team won't.15:58
programmerjakeuuh, doesn't the scalar-new prefix (not svp64) have a bunch of not-yet-defined bits?15:58
lkclremember they have no idea about Cray-style Vectors, at all15:59
lkclit does... and they're all 32-bit encodings15:59
lkcl(except for RM 24-bit Prefixing)15:59
lkclwhich is NOT permitted to be used for "instructions meaning something other than the exact same ones if they were not prefixed"15:59
programmerjakenot svp64-single...15:59
lkclbeen there done that (ld-st-with-shift)15:59
lkcleven svp64-single15:59
lkclhard rule.15:59
programmerjakeyou're missing i meant when the "new" bit is set.16:00
programmerjaketotally different than using existing 32-bit encodings16:00
lkclcreate the 32-bit encoding16:00
lkclprefix it.16:00
lkcl32-bit encoding MUST remain the same as when it is prefixed16:00
lkclNO space allocated - AT ALL - for "let's borrow bits of the SVP64/SVP64-Single space for 64-bit scalar instructions"16:00
lkclyes. including when new bit is set16:01
programmerjakewell, ld/st in svp64 borrows bits of the prefix to be new fields, iirc, why not setvl2 too?16:02
lkclactually it doesn't.16:02
lkcli _did_ make that mistake (ld-st-with-shift)16:02
lkclwas such a nightmare i backed it out16:02
lkcllearned the lesson, ain't doing it again16:03
lkclyou *might* be referring to "els" - element-strided16:03
lkclthat doesn't actually define "new fields"16:03
lkclit sort-of-cheats-by-modifying-the-immediate16:03
lkclbut doesn't *actually* alter the ld-st instruction *fields* nor their underlying meaning16:03
lkclld-st/els kinda cheats by multiplying the immediate by the element index :)16:04
lkcland feeding *that* to the LD/ST engine rather than the original immediate16:04
lkclssh, don't tell anyone :)16:04
* lkcl theatrically-loud whispering there16:05
programmerjakethe mistake with ld/st-shift imho was to repurpose existing fields already used by the 32-bit unprefixed op. what i'm suggesting doesn't, it uses fields of the *prefix* which we can assume setvl to be a new mode like ld/st or alu, allows those prefix fields to be defined differently.16:05
lkclhard-rule no16:05
lkclah wait....16:05
lkclthat's what i said, 5 mins ago.16:05
lkcla new RM mode.16:06
lkcli *don't* want to get into that right now16:06
lkclso i am cheating: i'm going to use the "Normal" (ALU) mode for now16:06
programmerjakeuuh, than how do you get away with ld/st *not* using the alu mode like any other svp64 op?16:06
lkclto shoe-horn sv.setvl in by borrowing the same bits allocated to pack/unpack at the moment16:07
programmerjakek, just put comments # to be replaced with setvl rm mode16:07
lkclld/st has its own (two) separate modes16:07
lkclRM.LD-immediate and RM.LD-indexed16:07
lkclhad to be that way. annoying.  took many months to develop16:07
* lkcl need to get back to sv.setvl16:08
programmerjakelikewise setvl can have its own separate mode, please mention that in a comment so we don't get stuck with setvl being normal mode and not having the space we need for extension16:08
ghostmansd[m]lkcl, so TODO was the reason?16:38
ghostmansd[m]The code indeed drops the instructions which have TODO somewhere16:38
ghostmansd[m]Because, well, what should be the value for these with validation?16:38
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:22
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc17:29
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC18:17
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc18:18
lkclghostmansd[m], sigh yes18:18
lkclexactly, duh18:18
lkclbut "setvl." is still stuffed.18:19
ghostmansd[m]You mean, even with TODO it doesn't work?18:19
ghostmansd[m]OK checking now18:19
programmerjakemassive regex to the rescue:;a=commitdiff;h=ecdbf851e42481ea43fff829458f0668f8d4076b18:25
programmerjakejust took the appropriate lines from minor_63.csv and pasted, then regex replace-all a few times18:26
ghostmansd[m]OK something got fucked up at PPC record level18:28
ghostmansd[m]We got both from mdwndb, but nothing at ppcdb18:28
*** ghostmansd <ghostmansd!> has joined #libre-soc18:29
ghostmansd[m]Ok the fix is trivial18:32
ghostmansd[m]The check was obviously wrong, no idea why it's written that way18:32
lkclprogrammerjake, :)18:32
programmerjakeit's not often that I'm working with a 30-ish line regex, but today was the day :)18:34
ghostmansd[m]Holy cow18:35
ghostmansd[m]lkcl, don't rebase yet18:35
lkclghostmansd[m], ack18:35
lkcloopsie... ValueError: CRIn2Sel.BB18:35
ghostmansd[m]This is why don't rebase18:36
ghostmansd[m]Now we're left with that crand error18:36
ghostmansd[m]But Rc tests should pass now18:36
*** tplaten <tplaten!> has joined #libre-soc18:37
* lkcl testing18:37
lkcl : instruction does not match 'sv.crand 3,0,33' expected 'sv.crand 12,2,33'18:37
lkclyep horrah that's the only one18:37
* lkcl running tests now18:37
ghostmansd[m]I'll try finding why it doesn't work18:37
ghostmansd[m]But frankly, I'm more surprised the vector one works18:38
ghostmansd[m]I mean, this is completely unexpected...18:38
lkclit's a.. oh... this is that BA_BB one isn't it18:38
lkclit's a 5-bit (like isel)18:39
lkclit _should_ be fine18:39
lkcli bet it's BA_BB-related18:39
lkclnot CR5Decoder related18:39
ghostmansd[m]Yeah but why it works with vectors?18:44
ghostmansd[m]sv.crand *16,*2,*33 works just fine18:45
ghostmansd[m]I bet Extra3 is doomed?18:48
ghostmansd[m]isel was Extra218:48
lkcldooomed, doooomed i say18:50
lkclyes that sounds reasonable18:50
ghostmansd[m]Well you know what?18:53
* lkcl huhn?18:53
ghostmansd[m]This is CR_BIT18:53
ghostmansd[m]So it should go to CR5Operand, right?18:54
ghostmansd[m]But I don't see this code called18:54
lkcloh whoops18:54
ghostmansd[m]Checking why on Earth18:54
lkclok 1 sec18:54
ghostmansd[m]Need to check more18:55
lkcl    CR_BIT = 3 # refers to one bit of the 32-bit CR register18:55
lkcl    BA = CR_BIT18:55
lkcl    BB = CR_BIT18:55
lkclurr i bet you it's down to BA_BB18:55
ghostmansd[m]Ah fuck18:56
ghostmansd[m]Ignore everything I wrote18:56
ghostmansd[m]I forgot to pull18:56
ghostmansd[m]And override the file18:56
ghostmansd[m]So obviously no code was called on Talos18:56
ghostmansdBT CR5Operand 4 3 218:58
ghostmansdBA CR5Operand 4 3 218:58
ghostmansdBB CR5Operand 4 3 218:58
ghostmansdc0 2c 40 05    sv.crand *16,*2,*3318:58
ghostmansd02 0a 02 4c18:58
ghostmansdBB CR5Operand 4 3 218:58
ghostmansd20 00 40 05    sv.crand 3,0,3318:58
ghostmansd02 0a 82 4d18:58
ghostmansdDeep breath18:58
ghostmansdThese 4 3 2 are shifts18:59
ghostmansdvector, scalar, spec18:59
ghostmansdThe last insn should've been sv.crand 12,2,3319:00
ghostmansdBut only the last operand was considered19:00
ghostmansd(and this is the only one correct)19:00
ghostmansdSo somehow it looks like we ended with spec=019:01
ghostmansdAnd I think I know why19:01
ghostmansdPerhaps we should call this sv_spec_leave even for the cases when spec was 019:03
ghostmansdBecause after sv_spec_enter we end up with 3 bits instead of 519:03
ghostmansdThat one cuts 2 bits19:03
ghostmansd(it's only for CR5 this crap happens)19:03
ghostmansdAnd spec_leave adds these 2 back19:03
ghostmansdWorked like charm19:04
ghostmansdSo far so good19:05
ghostmansdAll dis tests are fine19:05
ghostmansdBy the way any ideas how to call these better?19:05
ghostmansdI mean sv_spec_enter and sv_spec_leave19:05
ghostmansdThese are methods to be called on value and span BEFORE and AFTER messing with the spec19:05
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC19:30
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc19:30
lkcli'm just as bad at names as you21:11
lkclERROR: test_sv_remap_dct_cos_precompute_8 (__main__.DCTTestCase)21:11
lkclpre-computes a DCT COS table, deliberately using a lot of21:11
lkclTraceback (most recent call last):21:11
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 963, in __getattr__21:11
lkcl    return globals()[attr]21:11
lkclKeyError: 'FPCOS32'21:11
lkcli'm assuming that needs pywriter re-running21:11
lkclthat's likely the same thing - re-running it manually...21:13
lkclyyep, pywriter-rerun problem gone21:14
lkclyyep, ok21:15
lkclpython3 src/openpower/sv/trans/  > /tmp/f21:15
lkclRan 7 tests in 4.007s21:15
ghostmansd[m]That's great that we have these operands split, it really simplifies the operands handling.21:16
ghostmansd[m]This was an awesome idea.21:17
ghostmansd[m]We basically took all the benefits for no price.21:17
*** tplaten <tplaten!> has quit IRC21:18
lkcleh oh you mean the "cheating"?21:19
lkclghostmansd[m], tests pass, rebased21:41
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:45
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:45
ghostmansd[m]Hooray! Let's open the bottle of champagne? :-)22:10

Generated by 2.17.1 by Marius Gedminas - find it at!