IRC channel logs
2021-09-23.log
back to list of logs
<stikonas>cc_riscv64 can now compile M2-Planet but 1) M0 sometimes crashes on cc_riscv64 output M2.M1 (but not always), M1 always seems to work, so must be another bug in M0. 2) M2 binary segfaults fairly quickly, so probably some codegen bug in cc_riscv64 <stikonas>oriansj: do you want a PR for what I have now? <stikonas>even though it can't yet compile M2-Planet? <stikonas>ok 2) seems to be crash in memset... hopefully I can reproduce it with something smaller than M2-Planet <Hagfish>it's impressive that you're already narrowing down the second issue, and the first issue's non-determinism sounds frustrating <oriansj>stikonas: well the easiest way to trace the problem is to get RISC-V support into M2-Planet <stikonas>yeah, if my current path does not lead to fix, then I can try that... <oriansj>as it'll reduce the possible problem space by producing M1 output you can directly compare against <oriansj>you can also use the M2-Planet tests to validate cc_* as well <oriansj>You can also use M2-Planet on your sample tests to get a feel for what it should kinda look like. <stikonas>also, M2-Planet already needs indirect branching (branch and jump) <stikonas>one while loop was outside B format range... <stikonas>risc-v binary code is almost double for AMD64... <stikonas>I guess because cc_* does a lot of stack operations <oriansj>the inability to proper range checks for hex2+M1 for RISC-V also make it a bit harder as well <stikonas>yeah, I sometimes double check with M1 and full hex2 <xentrac>pabs3: yeah, I think you can still buy the GA144, which has 144 18-bit computers in a 12×12 array, lineal descendants of the MuP21. except now they run at about 1GHz instead of 20MHz or whatever the MuP21 did <xentrac>and you can't hook up external RAM to them, so they only have 64 words of RAM each <xentrac>it's in this weird gap between FPGAs and microcontrollers, both of which get a lot of usage <xentrac>but because you can't program it in either Verilog or C, it's really hard to use <pabs3>what kind of situations does GA144 get used in? almost zero RAM on a reasonably fast processor seems like a weird combo <xentrac>I've only ever seen research papers and tech demos, never a mass product <xentrac>the decision to leave out the multiplier was maybe not such a good one because otherwise it would be a great "TPU" <oriansj>stikonas: I just thought of a use for ^ in risc-v <oriansj>enabling and disabling range checks ^ -> no range check; no ^ -> range check with hand written hex2 treating ^ as a nop <oriansj>if you want to do ~label aupic + $label lui to get a 32bit absolute address into a register <oriansj>as if it is out of range for the lui it would throw a range check violation <pabs3>Lightning Talk seems worth doing <oriansj>I've submitted to a few over the last year. Thus far none have accepted; so clearly I am probably doing something very wrong. <pabs3>hmm, maybe get some tips from repro builds folks, they manage to get theirs accepted to lots of places <oriansj>perhaps their topic is just more relatable than hey We did some crazy shit, we think its cool and want to tell you about it. <Hagfish>really glad to see the top comment there is "we need bootstrappable, not just reproducible builds" and the top reply is "we have them, see bootstrappable.org" <clemens3>the argument is always with each and every new self dependent language, you need a gcc binary as well.. but I could argue, i use linux since 0.03 back in the day when it was done with assembler and since then i always used my own stuff, now how do I use a new language without first installing a blob.. if that is not given, a new project should be rejected.. easier said then done, thought.. <clemens3>rust now is needed for librsvg which is needed for goffice and then all bigger packages.. like epiphany <clemens3>rustc points to ocaml which needs ocaml by now as well <clemens3>and some poor lonely guy is doing the mrustc meanwhile, which builds on some setups, but not on mine so far.. <stikonas>ocaml -> rustc path by now is really long and probably not easy to do on modern systems <clemens3>yeah, but bootstrapped means, some guy did it once.. is still, where is my source.tar with a build.sh script that then really runs.. <stikonas>well yeah, ocaml build takes like 12hours or so... <clemens3>on a fast processor.. my best machine at the moment is 4 cores 8 threads <clemens3>soon without heavy epic processors or farms it will take months and years.. bloat is at the moment exponentially balloning <clemens3>the LFS build with X and a browser is at least 18 hours.. that is ok and bearable, but I don't want to know 2-3 years out.. <stikonas>well, building ungoogled-chromium on my laptop now takes the whole day <clemens3>then a normal desktop won't do it anymore or you need weeks <clemens3>because we don't get 50 or 100% more service <clemens3>still just simple html with a bunch of javascript, movies did run already years ago in a browser <clemens3>so what does give rust to firefox, just some self gratification, nothing for the rest <clemens3>and if you count the bootstraps it is not 24 hours i guess <clemens3>well, for 1-2 years it is necessary for my understanding <stikonas>yes, rustc from 1.39 to 1.5x probably takes 2 days or so <stikonas>but mrustc at least for now is still keeping up <clemens3>yes, which is ridiculous and in my eye is not open source anymore, if you can't build it, and you have a lot of dynamic downloads on the background.. <stikonas>I don't think you need dynamic downloads on the background... <clemens3>standard rustc needs some trickery to disable it, not? <stikonas>possibly... But package managers do disable it <stikonas>hmm, at least on Gentoo everything builds without network <stikonas>I would expect most other package managers also build in isolated environment without network <clemens3>but on gentoo, if i compile rust, well, you showed me the link, but that is not standard gentoo? there is some bin download first? <stikonas>clemens3: no, that's my overlay repository <clemens3>yeah, i know you work on the c/tinycc front, which is laudable.. just worried once you have gcc, it still gets more and more difficult <clemens3>yeah, i look at your scripts, very help full i will imagine, and great to have a source to ask back.. <clemens3>but just tell me, how is standard gentoo handling the rust mess? <stikonas>just install rustc-bin and then rebuild rustc is the standard way <clemens3>well, wrong place here to shake my head:) <clemens3>so open source and from source are now two different concepts <clemens3>thought a long time, before it was open source, you could built it from cpp <stikonas>e.g. bison was depending on bison and flex... <clemens3>unfortunately i once head a sun source tar ball, but i lost it.. like 1998 or so <stikonas>well, we do have bootstrap path from gcc to openjdk 7 <stikonas>and from there it's quite easy to go to 17 <clemens3>yeah, other topic, i tried once the guix route and got 5 packages far.. but i am not a guiler and failed at some classpath dev version.. <stikonas>well, I recreated guix'es openjdk bootstrap on Gentoo... <clemens3>ok, super, I will also definitely come back to you on that too <Hagfish>"Wow that Stage0 project is amazing, didn't realize anyone went that far, thanks for the reference!" <Hagfish>i'm glad that the achievements (and potential) of this project is really starting to click with the public, and it's starting to get traction (even if only in the bubble that i inhabit) <stikonas>oriansj: I'm still trying to debug cc_riscv64. I'll probably have to go step-by-step compare to amd64 version using gdb but maybe you have any other ideas what might be going wrong <stikonas>I guess something wrong with the stack...