<dddddd>let's see if I can fix that wasteful stack... <dddddd>It works, using X18 as stack pointer instead of the architectural one. Tomorrow I'll test on the metal and clean it up. <dddddd>~18 definitions and pretty much all the libc files are involved. <oriansj>fossy: a reduced kaem is a good idea (I'll need it when I go to write a kaem in assembly) <oriansj>markjenkinsznc: I can keep the build paths and move the pieces; I'll try to have that done tonight if possible <oriansj>dddddd: or you could save yourself some work and just change the definition for the instructions involving the stack register to just be the instruction using X18 and put clarifying details in the definition file. (then just reduce the stack offsets) and no other changes would be required <oriansj>The only people who would notice or care are those auditing the inline assembly or writing new libc primitives for M2-Planet <oriansj>janneke: I think I have a radical solution to making the porting of MesCC to new architectures alot simpler and possibly help me with an optimization question I had <dddddd>That's it, oriansj. The definitions using SP are now using x18 under the hood. I added SUB_* for the new offsets (8 and 24) --this is what triggers the changes in the libc; and added a definition to initialize X18 from SP. Then, cc_core.c changes for the "depth". <oriansj>It also means minimal changes for cc_aarch64 too <oriansj>tragic that no one on info-gnu@gnu.org, guix-devel@gnu.org, rb-general@lists.reproducible-builds.org or bootstrappable@freelists.org commented on the AArch64 porting news (or at all really) <dddddd>thanks for the announcements, oriansj. They'll react to bigger news, let's hope (: <lfam>Pretty good, no news to report :) <oriansj>lfam: well we just did 4 major releases in 5 days; Added a whole new architecture and completed a speed run which resulted in 5 compilers written in assembly being completed in 4 hours (with matching C versions too) <lfam>I saw that speed run comment in the release notes, I really liked it <lfam>Sometimes that's the only way it can happen <oriansj>dddddd: I don't know how the hell I am going to top this <oriansj>lfam: It is just that literally no one commented or responded in anyway. Like they were too busy watching the Superbowl or something to notice <lfam>I think that people don't quite understand the ramifications of your work yet <dddddd>oriansj, I'm thinking about the moment when all the pieces are complete. There's also FOSDEM with lots of interesting things. <oriansj>I'd say; The Hacker news post got -60 karma <lfam>Hitting on hacker news is really like winning the lottery unless the subject already has a very large audience <oriansj>plus I am still stuck on figuring out a good guile compatible test for modules for mes-m2 to do <oriansj>as it is one of the last major blockers for completing hex0->GCC <oriansj>The rest are trivial primitives that I could do in batches of 50 in a day <oriansj>dddddd: oh I forgot to mention your AArch64 work passed 12 hours of fuzzing with flying colors (No hangs or segfaults) <dddddd>We'll get there, oriansj. I'll try to help you with that testing of modules, I have to dig a bit into it yet. <oriansj>dddddd: your M2-Planet work is more critical (RISC-V) <oriansj>plus we need someone with deep understading of guile modules and where it is going to be in 5-10 years <oriansj>as mes-m2 needs to be able to be a drop in replacement for guile to solve the psyntax bootstrap problem and run guix (solving the guix bootstrap problem too) <oriansj>Plus the guix team has work on pulling The last remaining c++ pieces left over from nixos (if they haven't finished that while I wasn't looking) <oriansj>and the more architectures mescc-tools and M2-Planet support, the more platforms that guix can be effectively bootstrapped on via mes-m2 <dddddd>I'm sure missing many details; and you know what you're doing. But to me, that idea of a complete reimplementation of (present and future) guile feels... not quite right. <oriansj>dddddd: right now guile can't be bootstrapped even with GCC because of psyntax <dddddd>I'll review the logs, we talked about this. <oriansj>In the previous search we couldn't find a bootstrappable guile version that would allow us to bootstrap psyntax; now there might have been but I don't know about it <oriansj>and if there was, I could always throw x months at it; to make it buildable via M2-Planet and be done <oriansj>or do M2-Planet v2.x with all of the features it needs to be built and be done <oriansj>Then it is about making it be able to run guix and MesCC tools (along with porting to all hardware targets) <dddddd>Anyway, most of my focus is on the new targets of M2-Planet. <oriansj>good; that is very important to the future of M2-Planet <oriansj>part of me is tempted to just hack together a prototype for module support in scheme leveraging keywords and primitive-load (as mes-m2 already has them) and be done with it. <oriansj>maybe I just need a good night's sleep and the answer might magically appear before morning. <markjenkinsznc>oriansj, I hear you saying the recent surge of compilers and released has been under recognized. I'm impressed and looking forward to getting knightpies running all those fabulous new cc_* compilers written in knight assembly ***ng0_ is now known as ng0
<pgreco>janneke: were you able to check the gcc/ppc64le patches? <janneke>pgreco: i can't remember having seen (gcc) patches... <pgreco>janneke: what we talked about using the patches from 4.8.5 from CentOS <janneke>pgreco: right, thanks for reminding me <janneke>no, we haven't started on power9 yet; but this is certainly worth looking at <pgreco>good, let me know if there is anything I can help with <janneke>if you have an url ready, that's always handy <janneke>otherwise i've added it to my TODO, for when power9 comes up