IRC channel logs
2023-08-10.log
back to list of logs
<fossy>samplet: if you do ever get a chance to have a look at that syntax-case issue from ppsyntax, that would be amazing :) (no rush though) <stikonas>fossy: have you had any thoughts of what are we going to do with live-bootstrap on non-x86 arches? <stikonas>I think one of the development problems would be checksums... <stikonas>and the other is either requiring appropriate hardware or you have to inject qemu-user binaryinto the bootstrap <fossy>i haven't thought extensively about checksums yet.. <fossy>i think we probably need a slightly different long term solution to checksums <fossy>but what that is exactly i don't have a good solution for yet <stikonas>it might still be good to have them for releases <fossy>yeah, that was one option i was thinking - do a mass change at some interval <oriansj>fossy: have the architecture in the name of the checksum files? <fossy>oriansj: that is a simple solution for structuring it, but imo the larger problem is having to regenerate for every architecture <fossy>which often is not going to be very feasible for every PR <stikonas>oriansj: that is what I have been doing (archtecture in the checksum files) <oriansj>well ideally we would be only having to update the updated program and potentially the ones that use it <stikonas>but indeed, regenerating all arches will be tricky <fossy>yes, you only have to update the update program and all the ones that link to it <fossy>which is often quite expansive in live-bootstrap <oriansj>yeah, M2-Planet doesn't produce optimal code and an interpreters just run slower than compiled code. <fossy>M2-Planet is not the slow part of the bootstrap, lol <samplet>fossy: Well, I quickly tested the ‘define-macro’ trick discussed yesterday. On the modules branch, the script runs for quite a while (seems promising) and then crashes. I bumped Mes’s memory and stack limits, and it ran a bit longer and then tried to close file -1. <stikonas>fossy: M2-Planet is not slow, but some code it generates is slow... <samplet>Also, Mes is slow because Mes is slow. ;) <stikonas>if you feel that 20 minute build time on x86 is slow, try running it on riscv boards... <samplet>The other day I found code where it updated a character in a string by converting the string to a linked list, traversing the list to the given index, updating the character there, and then converting the list back into a string! <samplet>(I mean no disrespect, of course. You have to get things off the ground somehow. All I’m saying is that it’s never been optimized for perf.) <stikonas>and it was first written for x86 or something similar <stikonas>so other arches are often doing very suboptimal code <fossy>samplet: would you mind pastebinning that somewhere? <samplet>I think it might work now. The problem was no “mach.d” directory. We’ll see when it finishes.... <samplet>It wrote one action file and then crashed on the table file. The file differs from what NYACC ships, but looks equivalent to me. <fossy>yes, that matches my expectations <samplet>How so? The difference or crashing on table generation? <fossy>my bad, the file differing from shipped, but only being non-functional differences <samplet>Right. I wonder what NYACC is doing to print these. Is it using ‘pretty-print’? <samplet>Mes puts line breaks before lambda bodies, like a programmer would, while Guile doesn’t bother. Guile uses commas for unquoting, while Mes spells out ‘unquote’. <oriansj>stikonas: how does TCC take when built? <samplet>I’ll try again with the missing ‘string-every’ it was complaining about. <samplet>This is much more fun than figuring out why MesCC is failing tests. :) <oriansj>well, I am starting to wonder how much work it'll take to strip down TCC into something that M2-Planet can build <stikonas>oriansj: building tcc with mescc on my riscv board takes maybe 2 days <stikonas>the other 2 days are for building meslibc and mes <stikonas>oriansj: stage0-posix takes about 30 minutes <stikonas>and I can confirm that even mescc-tools when built with gcc are much faster <fossy>stikonas: whats the clock speed of that? <stikonas>but e.g. using modern gcc to build modern binutils on all 4 cores takes just over half an hour <oriansj>well M2-Planet binaries run at 80% the speed of Mescc binaries <oriansj>so if the tcc self-hosting step (when built by mescc) is reasonably fast; doing the work might be worth it in terms of total saved time but not if most of the time is spent there. <stikonas>and mes-m2 can't bootstrap tcc (even on x86) <stikonas>anyway, both M2-Planet built binaries and mescc built binaries are way way slower than gcc built binaries <oriansj>stikonas: no, I am thinking of skipping the mes.c/mescc steps and doing a fork of tcc which is buildable by M2-Planet <stikonas>oriansj: did you see on #guix-risc-v somebody might be even looking at that <stikonas>oriansj: but you'll find tcc code quite ugly... <stikonas>once letter variables all over the place <stikonas>compiler is directly outputing binary code (rather than assembling it) <notgull>Fabian Bellard code just looks like that I think <stikonas>yes, but that's just not helpful to your readers... <samplet>fossy: Okay. Mes on GCC can generate the C99 files. I imagine Mes on M2 could do it, too. I hit another snag with the CPP files. It’s solvable, but I have to move on for now. This is all on top of the future Mes 0.26, too. <samplet>Mes 0.26 has major changes that let me run the NYACC code directly, instead of futzing about with “.mes” files. <notgull>People make fun of me for my 3 lines of comment per one line of code ratio, but bit is why I do that <oriansj>stikonas: I can deal with ugly; the hard problem is finding time to work on it <oriansj>least you forget mes.c used to be unbuildable by even gcc (due to snarfing) <oriansj>nothing kills focus faster than a 3 year old who wants your attention *NOW* <muurkha>oriansj: yeah, I"ve been dealing with kid interruptions in a pairing session this evening <oriansj>Christoph: short version snarfing in this context refers to the fact that mes.c wasn't written in C but rather was code which after processing by a scheme program generated a C program. <oriansj>It initially allowed janneke to make rapid progress but ultimately turned into the biggest problem for closing the bootstrap gap between M2-Planet and mes.c that took more than a year to fix