| programmerjake | for 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 code | 07:21 |
|---|---|---|
| programmerjake | also, rewriting it will allow giving nicer error messages -- the current error messages are nearly undecipherable | 07:24 |
| programmerjake | i'd like to write it so it can be used with make or similar, to compile files in parallel | 07:26 |
| programmerjake | i'd like to write it in c++ or rust, though am willing to use python | 07:27 |
| programmerjake | i 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 compilers | 07:36 |
| programmerjake | i could pretty easily make it to also generate python, so we don't need 2 separate parsers | 07:37 |
| *** ghostmansd <ghostmansd!~ghostmans@91.205.170.135> has joined #libre-soc | 09:19 | |
| programmerjake | i 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 issue | 09:57 |
| programmerjake | i'm planning on submitting rfps on monday. | 09:57 |
| *** ghostmansd <ghostmansd!~ghostmans@91.205.170.135> has quit IRC | 10:50 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has joined #libre-soc | 11:03 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has joined #libre-soc | 11:11 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has quit IRC | 13:20 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has quit IRC | 13:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has joined #libre-soc | 13:42 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has quit IRC | 14:17 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has joined #libre-soc | 14:32 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has quit IRC | 14:50 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has joined #libre-soc | 14:51 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has quit IRC | 15:57 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.43.108> has joined #libre-soc | 15:58 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 16:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has quit IRC | 16:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has joined #libre-soc | 16:21 | |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 16:21 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 16:40 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 16:40 | |
| ghostmansd[m] | I vote against Rust or C++ for the same reason: they are barely maintainable. | 16:41 |
| lkcl | if the compiler was used even by 200 people it would begin to just about justify a rewrite. | 17:22 |
| lkcl | there are far higher priority tasks for such a resource-constrained team as ours. | 17:23 |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has joined #libre-soc | 17:46 | |
| programmerjake | rust is specifically designed to be highly maintainable, so i'm assuming you're referring to the low number of rust developers, which is a drawback | 17:52 |
| lkcl | no, i'm referring to the number of users of the pseudocode-to-python compiler. | 17:56 |
| programmerjake | lkcl: 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 |
| programmerjake | rust... was addressed at ghostmansd's comment | 17:57 |
| markos | as much as I like rust, I would not choose it unless there are at least 2-3 people equally proficient in it | 17:58 |
| markos | as for auto json output, there are tons of libraries for that for pretty much every language so it's not really a major advantage | 17:58 |
| programmerjake | imho it will be faster to rewrite the parser rather than try to munge our current mess into a pseudocode to c compiler | 17:58 |
| lkcl | i 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 pseudocode | 17:58 |
| lkcl | these techniques *in no way* justify the massive time and effort to do a total rewrite | 17:59 |
| lkcl | particularly given that you write 5 times more code than necessary to perform the same task | 17:59 |
| lkcl | markos: there aren't. jacob is the only person in the entire team advocating its use. absolutely everyone else detests it | 18:00 |
| programmerjake | imho 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 time | 18:00 |
| markos | I 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 language | 18:01 |
| lkcl | programmerjake, it's not happening. | 18:01 |
| lkcl | i'm not going to keep repeating that | 18:01 |
| markos | if it only had a syntax more similar to C I would probably choose it | 18:01 |
| markos | then again I never had to write anything complex in it | 18:02 |
| markos | so far at least | 18:02 |
| markos | for that reason I was more favourable towards D, but it had other problems -lack of proper simd support, garbage collection, etc | 18:03 |
| markos | so back to C/C++ it is | 18:03 |
| markos | but what I really really dislike about rust is cargo, it's a big downside for me, but I equally dislike pip, npm, etc | 18:04 |
| programmerjake | imho you should try writing some stuff in rust, it's waay better than c/c++ | 18:04 |
| programmerjake | you technically don't have to use cargo... | 18:04 |
| markos | programmerjake, 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 it | 18:05 |
| markos | well no, but it pretty much forces you to use, all building instructions everywhere assume that | 18:05 |
| programmerjake | that said imho cargo makes it waay easier, imho c++ is sorely missing something standardized like that | 18:06 |
| markos | debian devs have a very hard time trying to package rust stuff | 18:06 |
| markos | well, that's the same thing npm users say :) | 18:06 |
| programmerjake | iirc debian made a bunch of scripts for packaging rust stuff... | 18:07 |
| markos | and it still takes more time to support rust software than eg. plain C | 18:07 |
| markos | but 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 one | 18:08 |
| markos | most important is time | 18:08 |
| markos | in 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 |
| programmerjake | i disagree...if you don't use unstable nightly-only compiler features or experimental libraries rust is quite easy to maintain in my experience | 18:09 |
| programmerjake | k | 18:09 |
| markos | well, 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 target | 18:10 |
| markos | I think it's stable now | 18:10 |
| programmerjake | easier than c/c++ with it's spooky UB at a distance due to no memory lifetime checking... | 18:10 |
| markos | that's easily solvable in C++ nowadays, in C not so easy I agree | 18:11 |
| markos | but then again with C++ you carry around a lot of baggage | 18:11 |
| markos | I do agree that's a tough call, if I was starting now, I would definitely keep away from C++ | 18:12 |
| programmerjake | x86/arm intrinsics are stable (but i wouldn't necessarily recommend using them due to the mess, blame arm/intel), portable-simd isn't yet | 18:12 |
| markos | exactly, this is totally solved in C/C++ | 18:12 |
| markos | but unfortunately, pretty much everything performance oriented is still coded in C++ | 18:13 |
| markos | so even if people hate it, they still don't dare to move away from it | 18:13 |
| programmerjake | oh, really? show me a platform-independent simd gather/scatter and i'll believe you -- portable-simd has this, c/c++ doesn't really | 18:14 |
| markos | it's definitely not a language problem | 18:14 |
| markos | gather/scatter basically sucks in all platforms so why bother | 18:15 |
| programmerjake | imho it isn't totally solved in c/c++, just enough that people stop immediately complaining | 18:15 |
| markos | but iirc google's highway simd library handles that | 18:15 |
| programmerjake | it's nearly trivial to use on portable-simd | 18:15 |
| markos | I don't doubt that and it's great that you were able to do it there | 18:16 |
| markos | but I really doubt that lack of a portable gather scatter depends on rust's features, it's all unsafe code anyway | 18:17 |
| markos | in any case, I am not against rust | 18:17 |
| markos | in my previous 2 companies, I actively tried to convince the teams to start developing one of our next-gen projects in rust | 18:18 |
| markos | partly as I wanted to get more acquainted with the language | 18:18 |
| markos | but resistance was strong | 18:18 |
| markos | both from mgmt and other devs | 18:18 |
| markos | it'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 it | 18:19 |
| markos | and that is its biggest drawbacks | 18:19 |
| programmerjake | actually portable-simd is mostly safe code (from a user's perspective, internally it's unsafe), no unsafe needed to use it, including gather/scatter | 18:19 |
| markos | yes, of course, that's also one of the nice -but risky features- of rust | 18:20 |
| markos | it 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 problem | 18:21 |
| markos | at least with C, you know that it's always unsafe :) | 18:21 |
| markos | but most of the time I agree it's much much more rare to have unsafe code with rust | 18:22 |
| markos | anyway | 18:22 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 18:23 | |
| programmerjake | imho if you think code using unsafe internally makes it risky to use, you may misunderstand the benefit of unsafe...it 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 it | 18:23 |
| markos | if 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 best | 18:23 |
| programmerjake | well, luke has already been convinced to let me write kazan (vulkan driver) in rust | 18:24 |
| markos | programmerjake, 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 possible | 18:24 |
| markos | the rust compiler has no way to know if the unsafe instruction can cause such havoc | 18:25 |
| markos | so it's still possible to break things, just harder | 18:25 |
| lkcl | programmerjake, 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 followers | 18:26 |
| programmerjake | actually 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 enabled | 18:27 |
| lkcl | markos, 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 sign | 18:28 |
| programmerjake | it also has miri, a rust simulator specifically designed to catch ub | 18:29 |
| markos | from 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 circumstances | 18:31 |
| programmerjake | mozilla 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 companies | 18:31 |
| markos | I'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 compiler | 18:32 |
| markos | ^burden | 18:32 |
| programmerjake | it does, but that doesn't mean unsafe turns off all compiler checks, unsafe rust is still much safer than c | 18:33 |
| markos | I never disagreed there | 18:35 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has quit IRC | 18:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has joined #libre-soc | 18:35 | |
| markos | ooc, 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 |
| programmerjake | in 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 ast | 18:38 |
| programmerjake | markos: safe transmute...rust is working on getting the compiler to allow transmuting between types where the compiler can detect that it's safe | 18:39 |
| markos | nice | 18:40 |
| programmerjake | so you can safely transmute i8x16 to i32x4 | 18:40 |
| programmerjake | gtg, meeting family today and i need more sleep first | 18:42 |
| ghostmansd[m] | Guys, our log sucks | 18:45 |
| ghostmansd[m] | But at least until recent I had an option to disable it | 18:45 |
| ghostmansd[m] | Now even with SILENCELOG=true I have some bitching in logs | 18:45 |
| programmerjake | ah, i'll fix that | 18: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 stderr | 18:46 |
| ghostmansd[m] | Also, making log use print() is a terrible idea | 18:47 |
| ghostmansd[m] | Perhaps we should plan to switch to Python standard logging | 18:47 |
| programmerjake | +1 for python standard logging | 18:51 |
| programmerjake | ghostmansd: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=abb08466eff7dbbfe850ec3646431f2f565e19de | 18:58 |
| lkcl | frickin ell that's a lot of money https://bugs.libre-soc.org/show_bug.cgi?id=252 | 19:10 |
| lkcl | EUR 7,000 | 19:10 |
| lkcl | that's in *addition* to... ahh, it's allocated. | 19:11 |
| lkcl | ghostmansd[m]: https://bugs.libre-soc.org/show_bug.cgi?id=898 EUR 2500 for you | 19:11 |
| ghostmansd[m] | Yeah this is the one I'm working on, but it needs field generation in sv_binutils. | 19:12 |
| programmerjake | all the texture op funding...ok binutils and transcendentals are useful | 19:13 |
| ghostmansd[m] | I'm moving towards it, it'll be awesome. | 19:13 |
| lkcl | cesar's on https://bugs.libre-soc.org/show_bug.cgi?id=197 which is another big one (EUR 5000) | 19:14 |
| lkcl | parallel prefix in ISACaller https://bugs.libre-soc.org/show_bug.cgi?id=864 is another big one (EUR 3000) | 19:15 |
| lkcl | that needs integration/activation via sv/trans/svp64.py - addition of the assembler syntax. ghostmansd[m] i'll need to allocate you a budget for that | 19:17 |
| programmerjake | for binutils isn't that just adding 1 more option to the svp64 prefix...sounds pretty simple, the budget shouldn't need to be very big | 19:19 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has quit IRC | 19:20 | |
| lkcl | programmerjake, 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 |
| lkcl | making my head spin keeping track of it all | 19:21 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has joined #libre-soc | 19: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 october | 19:43 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.43.108> has quit IRC | 20:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.170.135> has joined #libre-soc | 20:57 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has quit IRC | 21:36 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!