Sunday, 2022-08-28

programmerjakefor the pseudo-code to c compiler, i'd like to write that. imho i should write a more proper parser for the pseudo-code, using a recursive descent parser rather than using ply, because our current code has lots of issues caused by having a haphazard design without type checking or variable tracking or anything else -- imho the parser should either error or the output should always operate correctly, no generating broken code07:21
programmerjakealso, rewriting it will allow giving nicer error messages -- the current error messages are nearly undecipherable07:24
programmerjakei'd like to write it so it can be used with make or similar, to compile files in parallel07:26
programmerjakei'd like to write it in c++ or rust, though am willing to use python07:27
programmerjakei prefer rust, it has lots of features making it easier to use for that, e.g. it can automatically generate code for dumping AST, or for outputting it as json. it also has features that can help with parsing, e.g. high-quality error reporting designed for compilers07:36
programmerjakei could pretty easily make it to also generate python, so we don't need 2 separate parsers07:37
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc09:19
programmerjakei would want to work on that after getting utf-8 checking working with svp64, by that point i expect the nlnet grants that expire in october to be effectively done, so that shouldn't be an issue09:57
programmerjakei'm planning on submitting rfps on monday.09:57
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC10:50
*** octavius <octavius!> has joined #libre-soc11:03
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc11:11
*** octavius <octavius!> has quit IRC13:20
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC13:36
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc13:42
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC14:17
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc14:32
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC14:50
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc14:51
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC15:57
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc15:58
*** josuah <josuah!~irc@> has quit IRC16:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:21
*** josuah <josuah!~irc@> has joined #libre-soc16:21
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC16:40
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc16:40
ghostmansd[m]I vote against Rust or C++ for the same reason: they are barely maintainable.16:41
lkclif the compiler was used even by 200 people it would begin to just about justify a rewrite.17:22
lkclthere are far higher priority tasks for such a resource-constrained team as ours.17:23
*** octavius <octavius!> has joined #libre-soc17:46
programmerjakerust is specifically designed to be highly maintainable, so i'm assuming you're referring to the low number of rust developers, which is a drawback17:52
lkclno, i'm referring to the number of users of the pseudocode-to-python compiler.17:56
programmerjakelkcl: well, in my experience from writing pseudocode only to have it mysteriously fail, so i have to guess why and change the code, sometimes repeating that process 4-5 times, it's currently barely usable.17:56
programmerjakerust... was addressed at ghostmansd's comment17:57
markosas much as I like rust, I would not choose it unless there are at least 2-3 people equally proficient in it17:58
markosas for auto json output, there are tons of libraries for that for pretty much every language so it's not really a major advantage17:58
programmerjakeimho it will be faster to rewrite the parser rather than try to munge our current mess into a pseudocode to c compiler17:58
lkcli have absolutely no problem whatsoever with making changes to the pseudocode, removing large sections, examining the output during a run and putting in debug print statements into the compiled output in order to debug pseudocode17:58
lkclthese techniques *in no way* justify the massive time and effort to do a total rewrite17:59
lkclparticularly given that you write 5 times more code than necessary to perform the same task17:59
lkclmarkos: there aren't.  jacob is the only person in the entire team advocating its use.  absolutely everyone else detests it18:00
programmerjakeimho rewriting and adding a c backend should take 2-3 weeks, trying to make the current compiler output c would take about the same amount of time18:00
markosI don't detest it, I actually like rust but I am in no way proficient enough to call myself anything more than a noob in the language18:01
lkclprogrammerjake, it's not happening.18:01
lkcli'm not going to keep repeating that18:01
markosif it only had a syntax more similar to C I would probably choose it18:01
markosthen again I never had to write anything complex in it18:02
markosso far at least18:02
markosfor that reason I was more favourable towards D, but it had other problems -lack of proper simd support, garbage collection, etc18:03
markosso back to C/C++ it is18:03
markosbut what I really really dislike about rust is cargo, it's a big downside for me, but I equally dislike pip, npm, etc18:04
programmerjakeimho you should try writing some stuff in rust, it's waay better than c/c++18:04
programmerjakeyou technically don't have to use cargo...18:04
markosprogrammerjake, unfortunately there is no time, and I find it unlikely someone paying me to actually learn the language now, if I were a student, I would definitely learn it18:05
markoswell no, but it pretty much forces you to use, all building instructions everywhere assume that18:05
programmerjakethat said imho cargo makes it waay easier, imho c++ is sorely missing something standardized like that18:06
markosdebian devs have a very hard time trying to package rust stuff18:06
markoswell, that's the same thing npm users say :)18:06
programmerjakeiirc debian made a bunch of scripts for packaging rust stuff...18:07
markosand it still takes more time to support rust software than eg. plain C18:07
markosbut anyway, that's not relevant to the discussion, it's just one of the things that keep me away from the language, but not the only one18:08
markosmost important is time18:08
markosin order to learn the language in a decent level you need to invest time, and in order to invest time, I have to take it from something else that pays the bills :-/18:09
programmerjakei disagree...if you don't use unstable nightly-only compiler features or experimental libraries rust is quite easy to maintain in my experience18:09
markoswell, for me simd was a one of the features that was experimental for a while, when I was looking at it, and iirc, the default simd package was not ready back then and a very moving target18:10
markosI think it's stable now18:10
programmerjakeeasier than c/c++ with it's spooky UB at a distance due to no memory lifetime checking...18:10
markosthat's easily solvable in C++ nowadays, in C not so easy I agree18:11
markosbut then again with C++ you carry around a lot of baggage18:11
markosI do agree that's a tough call, if I was starting now, I would definitely keep away from C++18:12
programmerjakex86/arm intrinsics are stable (but i wouldn't necessarily recommend using them due to the mess, blame arm/intel), portable-simd isn't yet18:12
markosexactly, this is totally solved in C/C++18:12
markosbut unfortunately, pretty much everything performance oriented is still coded in C++18:13
markosso even if people hate it, they still don't dare to move away from it18:13
programmerjakeoh, really? show me a platform-independent simd gather/scatter and i'll believe you -- portable-simd has this, c/c++ doesn't really18:14
markosit's definitely not a language problem18:14
markosgather/scatter basically sucks in all platforms so why bother18:15
programmerjakeimho it isn't totally solved in c/c++, just enough that people stop immediately complaining18:15
markosbut iirc google's highway simd library handles that18:15
programmerjakeit's nearly trivial to use on portable-simd18:15
markosI don't doubt that and it's great that you were able to do it there18:16
markosbut I really doubt that lack of a portable gather scatter depends on rust's features, it's all unsafe code anyway18:17
markosin any case, I am not against rust18:17
markosin my previous 2 companies, I actively tried to convince the teams to start developing one of our next-gen projects in rust18:18
markospartly as I wanted to get more acquainted with the language18:18
markosbut resistance was strong18:18
markosboth from mgmt and other devs18:18
markosit's really hard to beat the uncertainty of people, it has a very steep learning curve and most are afraid that they would be totally over the time budgets trying to master it18:19
markosand that is its biggest drawbacks18:19
programmerjakeactually portable-simd is mostly safe code (from a user's perspective, internally it's unsafe), no unsafe needed to use it, including gather/scatter18:19
markosyes, of course, that's also one of the nice -but risky features- of rust18:20
markosit advertises safe code, but it's only as safe as its dependencies, and if one is marked safe but is using potentially risky unsafe code, then it will cause a problem18:21
markosat least with C, you know that it's always unsafe :)18:21
markosbut most of the time I agree it's much much more rare to have unsafe code with rust18:22
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC18:23
programmerjakeimho if you think code using unsafe internally makes it risky to use, you may misunderstand the benefit of allows encapsulating unsafe such that the safe apis that use unsafe internally can be (and usually are) designed such that it's impossible to cause UB from the safe code using it18:23
markosif you manage to convince Luke about rust, I *would* be interested in getting involved, but mind you my level of coding in rust is apprentice at best18:23
programmerjakewell, luke has already been convinced to let me write kazan (vulkan driver) in rust18:24
markosprogrammerjake, no, I mean if the developer marks the dependency as safe, and its underlying unsafe code is buggy -eg. running a simd instruction that causes a trap- is still possible18:24
markosthe rust compiler has no way to know if the unsafe instruction can cause such havoc18:25
markosso it's still possible to break things, just harder18:25
lkclprogrammerjake, even that, retrospectively, was a mistake, as i had no idea how bad rust is in terms of adoption, readability, manageability, maintainability and scarily cult-like fervour amongst its followers18:26
programmerjakeactually it does, it has features specifically designed to prevent using instructions that aren't supported on your cpu -- functions with additional target features enabled are unsafe to call from functions with less target features enabled18:27
lkclmarkos, it's primarily recommended and advocated by the Mozilla Foundation, which if you know anything about the Mozilla Foundation and the pathological top-down behaviour of its Directors, it's not a good sign18:28
programmerjakeit also has miri, a rust simulator specifically designed to catch ub18:29
markosfrom a quick search it's quite possible to cause a segfault with unsafe rust, so apparently it's not able to catch everything, but that's beside the point, by definition unsafe means something that the compiler cannot vouch for, so you can be sure it may cause a potential problem under certain circumstances18:31
programmerjakemozilla is far from the only major organization advocating rust, in fact i'd say mozilla is only a minor component of rust's community now, since most of the rust team was laid off a few years ago. the devs have mostly kept working on rust but at other companies18:31
markosI'm not degrading unsafe code, I'm stating what I've read and been told numerous times, that unsafe code puts the burder to the developer to make sure it works as expected, and not the compiler18:32
programmerjakeit does, but that doesn't mean unsafe turns off all compiler checks, unsafe rust is still much safer than c18:33
markosI never disagreed there18:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc18:35
markosooc, iirc, rust is pretty strict about type casting, and with simd it's actually a needed feature to cast a vector to another type, how do you solve it? eg. converting a int8x16_t mask to eg. int32x4_t?18:37
programmerjakein any case, lkcl, can you let me try to write a better pseudocode -> c compiler for 2 weeks, if it isn't mostly working by then i'll stop...imho it would take a similar amount of time as trying to make our current compiler output c since it's tightly/messily integrated with generating python ast18:38
programmerjakemarkos: safe transmute...rust is working on getting the compiler to allow transmuting between types where the compiler can detect that it's safe18:39
programmerjakeso you can safely transmute i8x16 to i32x418:40
programmerjakegtg, meeting family today and i need more sleep first18:42
ghostmansd[m]Guys, our log sucks18:45
ghostmansd[m]But at least until recent I had an option to disable it18:45
ghostmansd[m]Now even with SILENCELOG=true I have some bitching in logs18:45
programmerjakeah, i'll fix that18:46
ghostmansd[m]When I say that I want the crap to be silent, this is exactly what I want :-)18:46
ghostmansd[m]Ok, please at least output it to stderr18:46
ghostmansd[m]Also, making log use print() is a terrible idea18:47
ghostmansd[m]Perhaps we should plan to switch to Python standard logging18:47
programmerjake+1 for python standard logging18:51
lkclfrickin ell that's a lot of money
lkclEUR 7,00019:10
lkclthat's in *addition* to... ahh, it's allocated.19:11
lkclghostmansd[m]: EUR 2500 for you19:11
ghostmansd[m]Yeah this is the one I'm working on, but it needs field generation in sv_binutils.19:12
programmerjakeall the texture op funding...ok binutils and transcendentals are useful19:13
ghostmansd[m]I'm moving towards it, it'll be awesome.19:13
lkclcesar's on which is another big one (EUR 5000)19:14
lkclparallel prefix in ISACaller is another big one (EUR 3000)19:15
lkclthat needs integration/activation via sv/trans/ - addition of the assembler syntax. ghostmansd[m] i'll need to allocate you a budget for that19:17
programmerjakefor binutils isn't that just adding 1 more option to the svp64 prefix...sounds pretty simple, the budget shouldn't need to be very big19:19
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC19:20
lkclprogrammerjake, we're out of budget in other areas so there's no location to give ghostmansd money for work he's done in other areas.19:20
lkclmaking my head spin keeping track of it all19:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc19:24
programmerjake<lkcl> "programmerjake, we're out of..." <- i figured that was the case...realistically there isn't time (and maybe not enough funding) to implement texture ops before october19:43
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC20:56
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc20:57
*** octavius <octavius!> has quit IRC21:36

Generated by 2.17.1 by Marius Gedminas - find it at!