| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 00:24 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has quit IRC | 00:48 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:04 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:04 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:20 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:19 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 04:43 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:55 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 05:19 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:19 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:09 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:34 | |
| programmerjake | openpower-isa failed in CI: | 08:34 |
|---|---|---|
| programmerjake | File "/builds/Kazan-team/mirrors/openpower-isa/src/openpower/sv/sv_analysis.py", line 181, in tformat | 08:34 |
| programmerjake | return "| " + ' | '.join(d) + " |" | 08:34 |
| programmerjake | TypeError: sequence item 3: expected str instance, NoneType found | 08:35 |
| programmerjake | make: *** [Makefile:14: svanalysis] Error 1 | 08:35 |
| programmerjake | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/commit/2659c01017f81aacf626fc021f937c417e5c4c2a | 08:35 |
| programmerjake | afaict that error blocks me working on fptrans, since if i can't run svanalysis, i can't run tests after modifying csvs and adding pseudocode | 08:37 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:01 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 09:05 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 09:05 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 09:06 | |
| programmerjake | bisected to https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/commit/3d5c12bb4cfde30c16e2de2b9581ab856694c6a2 | 09:08 |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 09:10 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 09:10 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 09:11 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 09:19 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 09:19 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 09:19 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 09:19 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 09:19 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:25 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 09:26 | |
| programmerjake | fixed: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=3caf0cb24d4311e288937e881b0fa31972d5bb0e | 09:28 |
| programmerjake | lkcl: svanalysis needs additional fixing because it miscategorizes the arguments for addpcis | 09:30 |
| programmerjake | but at least it won't block my working on fptrans anymorr | 09:30 |
| ghostmansd | such a nice and readable format they said | 09:46 |
| ghostmansd | missing comma: RAGE MODE ACTIVATED | 09:47 |
| programmerjake | ^ most of why i want to rewrite the pseudocode parser, because it's also like that | 09:50 |
| programmerjake | and not very understandable code due to the number of bodges | 09:51 |
| programmerjake | oh, well, later | 09:51 |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 10:01 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 10:01 | |
| *** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 10:01 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 10:01 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 10:02 | |
| lkcl | that's addpcis not having a known-format | 10:47 |
| lkcl | added yesterday | 10:47 |
| lkcl | what fun! | 10:48 |
| lkcl | both false objections, sorry folks. you miss a "}" in json format or a dictionary-entry it's exactly the same thing | 11:30 |
| lkcl | and no jacob rewriting the compiler because you don't understand it isn't a good reason to justify rewriting it | 11:30 |
| lkcl | the 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 mistake | 11:31 |
| programmerjake | uuh, you haven't seen my parser programming style before iirc... | 11:32 |
| programmerjake | also, 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 is | 11:35 |
| lkcl | it 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 deadlines | 11:35 |
| lkcl | worse than that it stops *you* from doing other much higher priority work | 11:36 |
| lkcl | this is about time and resource management | 11:36 |
| lkcl | the "kwahlliti" of the Kode can go f*** itself when time and resource management is concerned | 11:36 |
| lkcl | this is a practical pragmatic issue that you very much need to take on-board. | 11:37 |
| lkcl | every piece of work has to be thought of in terms of "where we are now, who understands what" | 11:37 |
| programmerjake | well, 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 long | 11:37 |
| lkcl | the actual lines of code is actually completely unimportant | 11:38 |
| lkcl | yep. | 11:38 |
| lkcl | i don't have a problem with it. | 11:38 |
| lkcl | i've *accepted* the limitations and compensated for it | 11:38 |
| lkcl | using exactly the same techniques that you say "take longer" | 11:38 |
| lkcl | i 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 |
| lkcl | i just get on with it | 11:39 |
| lkcl | bottom line stop grumbling and suck it up! :) | 11:39 |
| lkcl | when we have USD 40 million these things can be solved | 11:40 |
| programmerjake | well, by choosing to have very little error checking you've effectively made it waay harder for anyone but you to contribute | 11:40 |
| programmerjake | if 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 checkers | 11:44 |
| programmerjake | i've written at least 15 toy programming languages in the past, and several fully fledged ones | 11:44 |
| programmerjake | anyway, we already decided to not do that now, so we can talk about it more later rather than now | 11:46 |
| lkcl | dude: i find it *just as difficult*, the difference is, i *don't complain about it* | 11:57 |
| lkcl | i just suck it up and get on with it | 11:57 |
| lkcl | ghostmansd, clearly this is you https://www.youtube.com/watch?v=M6Ma57L97qU | 12:09 |
| ghostmansd | lol | 12:10 |
| ghostmansd | no actually I stand on the same position for now, due to time constraints | 12:11 |
| programmerjake | the view counter on that...26,263,636,336 .. seriously, 26 billion?! | 12:11 |
| ghostmansd | I don't like CSV and find it disgusting, but I understand the limitations | 12:11 |
| lkcl | and now for something completely different https://www.youtube.com/watch?v=3San3uKKHgg | 12:12 |
| ghostmansd | so that's why this "database" is not a database at all | 12:12 |
| ghostmansd | but, rather, putting all stuff we have now under the same roof | 12:12 |
| lkcl | yyep. | 12:12 |
| ghostmansd | (I obviously fixed and changed some stuff, but basically it is what it is) | 12:12 |
| lkcl | btw someone from IBM is also doing the same thing | 12:12 |
| lkcl | (a "database" machine-readable version of the spec) | 12:13 |
| ghostmansd | Well, practically speaking, we're safe to assume anybody now thinks of doing it (if not doing yet). | 12:14 |
| markos | I 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 whatever | 12:16 |
| markos | even sqlite would be better | 12:16 |
| * lkcl screams | 12:16 | |
| markos | having to edit CSV by hand is very suboptimal | 12:17 |
| markos | it'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 instruction | 12:18 |
| markos | well, ok, ignore sqlite :-P | 12:18 |
| markos | but I also understand that it's not a discussion for now | 12:19 |
| markos | OT | 12:19 |
| markos | lkcl, I was reading about a "new" language, supposedly C/C++ compatible but with some nice features | 12:20 |
| markos | Zig | 12:20 |
| ghostmansd | yes, I also checked it | 12: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 |
| ghostmansd | lkcl, by the way, how you do messages like "lkcl screams"? | 12:21 |
| ghostmansd | they are highlighted differently | 12:21 |
| markos | just write /me <text> | 12:21 |
| * ghostmansd tries | 12:21 | |
| ghostmansd | wow | 12:21 |
| * markos claps | 12:21 | |
| * ghostmansd is a king of IRC now! | 12:21 | |
| ghostmansd | Cool. Cool cool cool. | 12:22 |
| markos | it's only 30 years old tech, but sure :D | 12:22 |
| ghostmansd | :-D | 12:23 |
| ghostmansd | frankly to me IRC is, well, like ICQ | 12:23 |
| ghostmansd | (does anybody uses it still?) | 12:23 |
| markos | hahaha, another bleeding edge tech | 12:24 |
| markos | haven't used ICQ in over a decade | 12:24 |
| ghostmansd | one of Russian companies owns it now! | 12:24 |
| markos | and was one of the first adopters | 12:24 |
| programmerjake | i'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 needed | 12:24 |
| ghostmansd | I liked the compile-time tricks | 12:25 |
| ghostmansd | But I haven't used it, just read about it | 12:25 |
| ghostmansd | https://web.icq.com/ | 12:25 |
| markos | reg. 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 bonus | 12:25 |
| markos | smaller than Rust that is | 12:25 |
| ghostmansd | The site literally starts with ICQ -- the evolution of communication | 12:25 |
| programmerjake | imho rust is better because it's more mainstream and is actually proven safe, zig is more like c/c++ in terms of memory safety | 12:26 |
| ghostmansd | Forget Rust, forget Zig. Let's persuade lkcl to migrate to ICQ. | 12:26 |
| markos | I think Rust will never replace C/C++ in that regard, complement yes, replace no | 12:26 |
| ghostmansd | We want to be on the bleeding edge! | 12:26 |
| markos | so there is definitely a place for new languages that want to improve C/C++ code | 12:27 |
| programmerjake | rust's cross-compile support is very good, but not up to zig's level | 12:27 |
| markos | even Google rolled out their own language for that matter, Carbon iirc | 12:27 |
| markos | which also looks similar to Zig | 12:27 |
| markos | the problem is that C/C++ codebase is absolutely enormous | 12:27 |
| programmerjake | google, on carbon's page (paraphrasing): if you need c++ interop, use carbon, otherwise use rust | 12:28 |
| markos | much easier to incrementally improve this codebase with a better compiler that doesn't require total rewrite | 12:28 |
| markos | well ofc I wouldn't expect Google to advocate eg. Zig :) | 12:28 |
| ghostmansd | now you fundamentally eliminated one of the reasons Rust exists: to rewrite stuff for no other reason than doing it in Rust :-) | 12:29 |
| programmerjake | in particular, rust is still better even if you need c (but not c++) interop | 12:29 |
| markos | if I was 20y old and starting now in CS, I would probably learn Rust | 12:29 |
| markos | but right now this is out of the question for me, there is just no time | 12:30 |
| ghostmansd | Seriously, 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 |
| ghostmansd | Perhaps even have now. | 12:30 |
| markos | if it was a small codebase sure | 12:30 |
| ghostmansd | I cannot look at it with a serious face. | 12:30 |
| markos | but try doing that with >1M SLOC of C/C++ | 12:30 |
| ghostmansd | Rewriting just for the mere fact of rewriting? No thanks. | 12:30 |
| markos | it would take years and even then the benefits would be small | 12:31 |
| programmerjake | rewriting for better memory safety and better abstractions, enabling higher performance due to better algorithms/datastructures enabled by better abstractions | 12:32 |
| markos | it 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 it | 12:32 |
| markos | I honestly disagree there, the same algorithms can be implemented in whatever language you choose | 12:32 |
| markos | well, obviously I'm not comparing python to Rust/C here | 12:33 |
| programmerjake | well, 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 abstractions | 12:33 |
| ghostmansd | Yehyeh, the same old incantation | 12:33 |
| programmerjake | doesn't mean it's false... | 12:34 |
| markos | programmerjake, if you're talking about STL, perhaps, but C++ has a ton of fast hashtable projects out there | 12:34 |
| markos | and it's usually just a case of adding an #include | 12:34 |
| ghostmansd | nah, I'd reserve Rust for some whistles and bells | 12:34 |
| ghostmansd | pet project -- perhaps | 12:34 |
| ghostmansd | nothing serious though | 12:35 |
| programmerjake | the issue with c/c++ is it makes using better datastructures quite hard, especially for c, rust tends to make it pretty easy | 12:35 |
| ghostmansd | same for zig, even though it looks way better and has less hype around by order of magnitude | 12:35 |
| markos | C enables some serious low level bitbanging tricks that are just impossible anywhere else, which is one of its strengths | 12:36 |
| ghostmansd | ...and now the incantation about unsafe | 12:36 |
| markos | it's not about serious vs pet project, for me it's about codesize | 12:36 |
| programmerjake | uuh, 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't | 12:37 |
| programmerjake | e.g. loading a file into memory and reinterpreting as a struct | 12:37 |
| markos | which is one its strengths, exactly | 12:38 |
| markos | anyway, 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 argument | 12:41 |
| programmerjake | also 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 |
| programmerjake | bitwise rotate | 12:42 |
| markos | these are all trivial to implement in C and have already been optimized since ages, it's not entirely a novelty | 12:43 |
| programmerjake | rust 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 enabled | 12:45 |
| markos | for 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. boost | 12:45 |
| markos | only thing that puts me away is the syntx | 12:46 |
| markos | ^syntax | 12:46 |
| markos | when you write code in C/C++ for 30 years, Rust feels really weird | 12:46 |
| markos | well for me at least | 12:47 |
| programmerjake | imho 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 traits | 12:47 |
| programmerjake | and 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 nonexistant | 12:50 |
| programmerjake | and it doesn't have c++'s SFINAE nonsense | 12:52 |
| markos | C++ 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 years | 12:55 |
| markos | now if someone decided to fund such a project, that would be a different matter | 12:56 |
| markos | eg. 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++ codebase | 12:58 |
| markos | but I wouldn't do it just because Rust is better | 12:58 |
| markos | however, 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 works | 12:59 |
| programmerjake | if you want to port a small part of a c++ codebase to rust to try it out, look at https://cxx.rs/ | 13:01 |
| markos | interesting, thanks for the link | 13:03 |
| programmerjake | if you want more traditional c ffi, checkout bindgen and cbindgen, they translate c headers to rust and rust to c headers | 13:04 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 13:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.191> has joined #libre-soc | 14:18 | |
| lkcl | ghostmansd[m], poke, poke: "setvl." isn't reconstructed (test_pysvp64dis.py) - committing in 1 sec... | 15:29 |
| lkcl | but add add. addo addo. do. huhn. | 15:31 |
| ghostmansd[m] | I don't get, Rc isn't constructed? | 15:32 |
| lkcl | Rc=1 is not picked up by pysvp64dis. | 15:33 |
| lkcl | the "." is not placed onto the end of the word "setvl" | 15:33 |
| lkcl | where it is for "add." | 15:33 |
| ghostmansd[m] | . is not to be added by dis | 15: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 do | 15:34 |
| lkcl | * setvl RT,RA,SVi,vf,vs,ms | 15:34 |
| lkcl | * setvl. RT,RA,SVi,vf,vs,ms | 15:34 |
| lkcl | yes | 15:34 |
| ghostmansd[m] | With (Rc=1)? | 15:34 |
| ghostmansd[m] | If not — these are same | 15:35 |
| lkcl | err... ah! | 15:35 |
| ghostmansd[m] | You forgot to differ these | 15:35 |
| lkcl | ah ha! | 15:35 |
| lkcl | got it | 15:35 |
| ghostmansd[m] | Rc=0, Rc=1 | 15:35 |
| ghostmansd[m] | Respectively | 15:35 |
| lkcl | ah _ha_ :) | 15:35 |
| lkcl | bleh that now became : instruction does not match '.long 0x58a409b7' expected 'setvl. 5,4,5,0,1,1 | 15:36 |
| lkcl | but hey :) | 15:36 |
| ghostmansd[m] | Lol | 15:36 |
| ghostmansd[m] | Fields.text lacks Rc? | 15:36 |
| ghostmansd[m] | As a guess | 15:36 |
| * lkcl checking | 15:36 | |
| ghostmansd[m] | I'm AFK so cannot tell for sure | 15:36 |
| lkcl | ack | 15:36 |
| lkcl | hmm it's there. Rc=1 SVL-Form | 15: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, TLI | 15:37 |
| ghostmansd[m] | Hm | 15:39 |
| lkcl | huhn?? o dear. if only one instruction then it works | 15:39 |
| lkcl | like | 15:39 |
| lkcl | comment-out the other instructions in the test | 15:39 |
| lkcl | o dearie me | 15:39 |
| ghostmansd[m] | I think it has to do with name matching | 15:40 |
| lkcl | i do hate it when that happens | 15:40 |
| ghostmansd[m] | Check around exact_match et al. | 15:40 |
| lkcl | what i'll do is just split these for now into separate tests. | 15:40 |
| lkcl | i need to deal with something else | 15: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 else | 15:41 |
| ghostmansd[m] | Hopefully remap for Idx_1_2? :-D | 15:41 |
| *** octavius <octavius!~octavius@190.147.93.209.dyn.plus.net> has joined #libre-soc | 15:45 | |
| lkcl | urrrr they're both RA_OR_ZERO and RT_OR_ZERO, urrrr | 15:46 |
| lkcl | ferrr... urrr | 15:46 |
| lkcl | ha ha very funny, sv_analysis marked the regtypes of sv.setvl as "TODO". most droll | 15:48 |
| programmerjake | imho sv.setvl should be reserved for when we come up with schemes for extending the regfile | 15:50 |
| lkcl | programmerjake: https://bugs.libre-soc.org/show_bug.cgi?id=871 | 15:50 |
| programmerjake | ok, 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 marked | 15:52 |
| programmerjake | those bits allow selecting different extended regfile modes, tbd | 15:53 |
| lkcl | i'm not even going to do anything other than hack this. | 15:53 |
| lkcl | for now | 15:53 |
| lkcl | i'm overloading the "normal" encoding | 15:53 |
| lkcl | the task of creating yet another RM mode-format i'm not even going to look at | 15:53 |
| lkcl | the focus right now is to get Pack/Unpack completed | 15:54 |
| programmerjake | though 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 |
| lkcl | takes up another precious 32-bit 5/6-bit XO | 15:55 |
| programmerjake | ^ when we add extended regfiles, not now | 15:55 |
| lkcl | but those are only 32-bit encodings within a 64-bit space | 15:55 |
| lkcl | we need an excuse to justify setvl going into EXT000-063 and it being an SVP64-prefixable one makes that possible | 15:56 |
| lkcl | if it isn't then the ISA WG could reasonably argue that setvl *only* go into the new 64-bit space | 15:56 |
| programmerjake | the prefix has a bunch of bits that can be used for encoding new fields, like v3.1's prefix | 15:57 |
| lkcl | which would have the rather disastrous consequences of punishing absolutely every single cray-vector algorithm | 15:57 |
| lkcl | no it doesn't, that's the point. | 15:57 |
| programmerjake | reason to have 32-bit setvl: it's a common op | 15:57 |
| lkcl | (except if you define a new RM Mode) | 15:57 |
| lkcl | yes. you and i know that | 15:58 |
| lkcl | the ISA WG might be convinced of that | 15:58 |
| lkcl | but the compiler team won't. | 15:58 |
| lkcl | (necessarily) | 15:58 |
| programmerjake | uuh, doesn't the scalar-new prefix (not svp64) have a bunch of not-yet-defined bits? | 15:58 |
| lkcl | remember they have no idea about Cray-style Vectors, at all | 15:59 |
| lkcl | it does... and they're all 32-bit encodings | 15:59 |
| lkcl | (except for RM 24-bit Prefixing) | 15:59 |
| lkcl | which is NOT permitted to be used for "instructions meaning something other than the exact same ones if they were not prefixed" | 15:59 |
| programmerjake | not svp64-single... | 15:59 |
| lkcl | been there done that (ld-st-with-shift) | 15:59 |
| lkcl | even svp64-single | 15:59 |
| lkcl | hard rule. | 15:59 |
| programmerjake | you're missing i meant when the "new" bit is set. | 16:00 |
| programmerjake | totally different than using existing 32-bit encodings | 16:00 |
| lkcl | create the 32-bit encoding | 16:00 |
| lkcl | prefix it. | 16:00 |
| lkcl | 32-bit encoding MUST remain the same as when it is prefixed | 16:00 |
| lkcl | NO space allocated - AT ALL - for "let's borrow bits of the SVP64/SVP64-Single space for 64-bit scalar instructions" | 16:00 |
| lkcl | hard-rule-prohibited | 16:00 |
| lkcl | yes. including when new bit is set | 16:01 |
| lkcl | hard-rule-prohibited | 16:01 |
| programmerjake | well, ld/st in svp64 borrows bits of the prefix to be new fields, iirc, why not setvl2 too? | 16:02 |
| lkcl | actually it doesn't. | 16:02 |
| lkcl | i _did_ make that mistake (ld-st-with-shift) | 16:02 |
| lkcl | was such a nightmare i backed it out | 16:02 |
| lkcl | learned the lesson, ain't doing it again | 16:03 |
| lkcl | you *might* be referring to "els" - element-strided | 16:03 |
| lkcl | that doesn't actually define "new fields" | 16:03 |
| lkcl | it sort-of-cheats-by-modifying-the-immediate | 16:03 |
| lkcl | but doesn't *actually* alter the ld-st instruction *fields* nor their underlying meaning | 16:03 |
| lkcl | ld-st/els kinda cheats by multiplying the immediate by the element index :) | 16:04 |
| lkcl | and feeding *that* to the LD/ST engine rather than the original immediate | 16:04 |
| lkcl | ssh, don't tell anyone :) | 16:04 |
| * lkcl theatrically-loud whispering there | 16:05 | |
| programmerjake | the 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 |
| lkcl | yes. | 16:05 |
| lkcl | no. | 16:05 |
| lkcl | hard-rule no | 16:05 |
| lkcl | ah wait.... | 16:05 |
| lkcl | yes. | 16:05 |
| lkcl | that's what i said, 5 mins ago. | 16:05 |
| lkcl | a new RM mode. | 16:06 |
| lkcl | but | 16:06 |
| lkcl | i *don't* want to get into that right now | 16:06 |
| lkcl | so i am cheating: i'm going to use the "Normal" (ALU) mode for now | 16:06 |
| programmerjake | uuh, than how do you get away with ld/st *not* using the alu mode like any other svp64 op? | 16:06 |
| lkcl | to shoe-horn sv.setvl in by borrowing the same bits allocated to pack/unpack at the moment | 16:07 |
| programmerjake | k, just put comments # to be replaced with setvl rm mode | 16:07 |
| lkcl | ld/st has its own (two) separate modes | 16:07 |
| lkcl | RM.LD-immediate and RM.LD-indexed | 16:07 |
| lkcl | had to be that way. annoying. took many months to develop | 16:07 |
| * lkcl need to get back to sv.setvl | 16:08 | |
| lkcl | willdo | 16:08 |
| programmerjake | likewise 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 extension | 16:08 |
| programmerjake | thx | 16:09 |
| ghostmansd[m] | lkcl, so TODO was the reason? | 16:38 |
| ghostmansd[m] | The code indeed drops the instructions which have TODO somewhere | 16:38 |
| ghostmansd[m] | Because, well, what should be the value for these with validation? | 16:38 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.53.191> has quit IRC | 17:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:29 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 18:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 18:18 | |
| lkcl | ghostmansd[m], sigh yes | 18:18 |
| lkcl | exactly, duh | 18:18 |
| lkcl | but "setvl." is still stuffed. | 18:19 |
| ghostmansd[m] | You mean, even with TODO it doesn't work? | 18:19 |
| ghostmansd[m] | OK checking now | 18:19 |
| programmerjake | massive regex to the rescue: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=ecdbf851e42481ea43fff829458f0668f8d4076b | 18:25 |
| programmerjake | just took the appropriate lines from minor_63.csv and pasted, then regex replace-all a few times | 18:26 |
| ghostmansd[m] | Whoa | 18:28 |
| ghostmansd[m] | OK something got fucked up at PPC record level | 18:28 |
| ghostmansd[m] | We got both from mdwndb, but nothing at ppcdb | 18:28 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:29 | |
| ghostmansd[m] | Ok the fix is trivial | 18:32 |
| lkcl | joy | 18:32 |
| ghostmansd[m] | The check was obviously wrong, no idea why it's written that way | 18:32 |
| lkcl | programmerjake, :) | 18:32 |
| programmerjake | it's not often that I'm working with a 30-ish line regex, but today was the day :) | 18:34 |
| ghostmansd[m] | Holy cow | 18:35 |
| ghostmansd[m] | lkcl, don't rebase yet | 18:35 |
| lkcl | ghostmansd[m], ack | 18:35 |
| lkcl | oopsie... ValueError: CRIn2Sel.BB | 18:35 |
| ghostmansd[m] | Yeah | 18:36 |
| ghostmansd[m] | This is why don't rebase | 18:36 |
| ghostmansd[m] | Pushed | 18:36 |
| ghostmansd[m] | Now we're left with that crand error | 18:36 |
| ghostmansd[m] | But Rc tests should pass now | 18:36 |
| *** tplaten <tplaten!~isengaara@55d4426b.access.ecotel.net> has joined #libre-soc | 18:37 | |
| * lkcl testing | 18:37 | |
| lkcl | yay! | 18:37 |
| lkcl | : instruction does not match 'sv.crand 3,0,33' expected 'sv.crand 12,2,33' | 18:37 |
| lkcl | yep horrah that's the only one | 18:37 |
| * lkcl running tests now | 18:37 | |
| ghostmansd[m] | Cool | 18:37 |
| ghostmansd[m] | I'll try finding why it doesn't work | 18:37 |
| ghostmansd[m] | But frankly, I'm more surprised the vector one works | 18:38 |
| ghostmansd[m] | I mean, this is completely unexpected... | 18:38 |
| lkcl | it's a.. oh... this is that BA_BB one isn't it | 18:38 |
| lkcl | it's a 5-bit (like isel) | 18:39 |
| lkcl | it _should_ be fine | 18:39 |
| lkcl | i bet it's BA_BB-related | 18:39 |
| lkcl | not CR5Decoder related | 18:39 |
| ghostmansd[m] | Yeah but why it works with vectors? | 18:44 |
| ghostmansd[m] | sv.crand *16,*2,*33 works just fine | 18:45 |
| ghostmansd[m] | Hm | 18:48 |
| ghostmansd[m] | I bet Extra3 is doomed? | 18:48 |
| ghostmansd[m] | isel was Extra2 | 18:48 |
| lkcl | dooomed, doooomed i say | 18:50 |
| lkcl | yes that sounds reasonable | 18:50 |
| ghostmansd[m] | Lol | 18:52 |
| ghostmansd[m] | Well you know what? | 18:53 |
| * lkcl huhn? | 18:53 | |
| ghostmansd[m] | This is CR_BIT | 18:53 |
| lkcl | yaaa? | 18:53 |
| ghostmansd[m] | So it should go to CR5Operand, right? | 18:54 |
| lkcl | yaaaaa | 18:54 |
| ghostmansd[m] | But I don't see this code called | 18:54 |
| lkcl | oh whoops | 18:54 |
| ghostmansd[m] | Checking why on Earth | 18:54 |
| lkcl | ok 1 sec | 18:54 |
| lkcl | urrr | 18:54 |
| ghostmansd[m] | Need to check more | 18:55 |
| lkcl | CR_BIT = 3 # refers to one bit of the 32-bit CR register | 18:55 |
| lkcl | BA = CR_BIT | 18:55 |
| lkcl | BB = CR_BIT | 18:55 |
| lkcl | urr i bet you it's down to BA_BB | 18:55 |
| ghostmansd[m] | Ah fuck | 18:56 |
| ghostmansd[m] | Ignore everything I wrote | 18:56 |
| ghostmansd[m] | I forgot to pull | 18:56 |
| lkcl | burble? | 18:56 |
| ghostmansd[m] | And override the file | 18:56 |
| ghostmansd[m] | So obviously no code was called on Talos | 18:56 |
| lkcl | yaaaay | 18:57 |
| ghostmansd[m] | WAT | 18:58 |
| ghostmansd | BT CR5Operand 4 3 2 | 18:58 |
| ghostmansd | BA CR5Operand 4 3 2 | 18:58 |
| ghostmansd | BB CR5Operand 4 3 2 | 18:58 |
| ghostmansd | c0 2c 40 05 sv.crand *16,*2,*33 | 18:58 |
| ghostmansd | 02 0a 02 4c | 18:58 |
| ghostmansd | BB CR5Operand 4 3 2 | 18:58 |
| ghostmansd | 20 00 40 05 sv.crand 3,0,33 | 18:58 |
| ghostmansd | 02 0a 82 4d | 18:58 |
| ghostmansd | Deep breath | 18:58 |
| ghostmansd | These 4 3 2 are shifts | 18:59 |
| ghostmansd | vector, scalar, spec | 18:59 |
| ghostmansd | The last insn should've been sv.crand 12,2,33 | 19:00 |
| ghostmansd | But only the last operand was considered | 19:00 |
| ghostmansd | (and this is the only one correct) | 19:00 |
| ghostmansd | So somehow it looks like we ended with spec=0 | 19:01 |
| ghostmansd | And I think I know why | 19:01 |
| ghostmansd | Perhaps we should call this sv_spec_leave even for the cases when spec was 0 | 19:03 |
| ghostmansd | Because after sv_spec_enter we end up with 3 bits instead of 5 | 19:03 |
| ghostmansd | That one cuts 2 bits | 19:03 |
| ghostmansd | (it's only for CR5 this crap happens) | 19:03 |
| ghostmansd | And spec_leave adds these 2 back | 19:03 |
| ghostmansd | YEP | 19:04 |
| ghostmansd | Worked like charm | 19:04 |
| ghostmansd | So far so good | 19:05 |
| ghostmansd | All dis tests are fine | 19:05 |
| ghostmansd | By the way any ideas how to call these better? | 19:05 |
| ghostmansd | I mean sv_spec_enter and sv_spec_leave | 19:05 |
| ghostmansd | These are methods to be called on value and span BEFORE and AFTER messing with the spec | 19:05 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 19:30 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 19:30 | |
| lkcl | hooraay | 21:10 |
| lkcl | pffh | 21:11 |
| lkcl | i'm just as bad at names as you | 21:11 |
| lkcl | programmerjake, | 21:11 |
| lkcl | ERROR: test_sv_remap_dct_cos_precompute_8 (__main__.DCTTestCase) | 21:11 |
| lkcl | pre-computes a DCT COS table, deliberately using a lot of | 21:11 |
| lkcl | ---------------------------------------------------------------------- | 21:11 |
| lkcl | Traceback (most recent call last): | 21:11 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/helpers.py", line 963, in __getattr__ | 21:11 |
| lkcl | return globals()[attr] | 21:11 |
| lkcl | KeyError: 'FPCOS32' | 21:11 |
| lkcl | i'm assuming that needs pywriter re-running | 21:11 |
| lkcl | FAILED test_caller_transcendentals.py::FPTranscendentalsTestCase::test_fp_coss_cvt | 21:13 |
| lkcl | that's likely the same thing - re-running it manually... | 21:13 |
| lkcl | yyep, pywriter-rerun problem gone | 21:14 |
| lkcl | yyep, test_caller_transcendentals.py ok | 21:15 |
| lkcl | wha-hey! | 21:15 |
| lkcl | python3 src/openpower/sv/trans/test_pysvp64dis.py > /tmp/f | 21:15 |
| lkcl | Ran 7 tests in 4.007s | 21:15 |
| lkcl | OK | 21: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!~isengaara@55d4426b.access.ecotel.net> has quit IRC | 21:18 | |
| lkcl | eh oh you mean the "cheating"? | 21:19 |
| lkcl | :) | 21:19 |
| lkcl | ghostmansd[m], tests pass, rebased | 21:41 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:45 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:45 | |
| ghostmansd[m] | Hooray! Let's open the bottle of champagne? :-) | 22:10 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!