<stikonas>but building mes-m2->tcc still ends up faster than mes-m2->mes->tcc <stikonas>I guess the one built by gcc would be even faster <achaninja>for testing im just using guile because i presume its much faster than mes <stikonas>though building guile 3 is much slower than building mes <stikonas>but I guess you don't count guile building time <achaninja>im really curious if i can build some c compilers other than tinycc with mes <achaninja>I guess it might not work, each new codebase probably uses different C features <stikonas>achaninja: yes, that's an interesting question for which we don't know the answer <rkeene>It's great for compiling your C code to BF, which can then be run by a trival BF VM <rkeene>Or you can compile your C code to C, which you can then use a C compiler to compile. <stikonas>although I doubt that any other compiler would be as capable as tcc <stikonas>though maybe it can replace tcc 0.9.26 stage <achaninja>the main advantage of tcc is the embedded assembler <muurkha>rkeene: when I wrote my first BF interpreter I immediately ran Linus Åkesson's game of life in it <achaninja>rkeene: what do you mean by system oriented? <muurkha>I was impressed by how the BF spec was enough to go from zero to a virtual machine capable of running GoL in half an hour <rkeene>achaninja, It has an assembler which understands code/data split and instead of "." and ",", it has an interrupt vector (and the assembler knows how to register interupt handlers) <fossy>janneke: ah, ok, that is good! thank you for the update <rkeene>It has some default interrupt handlers -- Halt, Print String, Print Char, Get Char, but others could also be added (and the program being executed can supply its own) <muurkha>and I wondered if it would be possible to do something similar that avoided BF's most egregious defects, like the lack of subroutines <muurkha>it seems like your "interrupts" are really subroutines? <muurkha>I mean they don't get invoked asynchronously, do they? <rkeene>I don't know what asynchronously means here, but the handler is invoked when the interrupt is triggered and there's no stack, so.. possibly ? <rkeene>There's kind of a stack, but only for the instruction pointer <muurkha>well, I mean, in hardware, your keyboard interrupt might get invoked in the middle of some processing loop where the program is iterating over a lot of data <muurkha>the loop gets paused, the keyboard interrupt handler runs to, say, read the keystroke into a buffer, and then it resumes the processing loop <muurkha>by "asynchronously" I mean the interrupt handler runs independent of what the current instructions being run are <rkeene>That could occur here too, if we had hardware interrupts wired up to something; You would have the IP saved, jump to the interrupt handler, and it could do something (hopefully saving the current DP -- that's not done automatically in what's implemented, but maybe it should be), and return (which resets IP) <muurkha>right, but that isn't what you're using them for, is it? <rkeene>No, I only implemented the same interrupts as BF had -- I just also made it extensible and overridable <rkeene>I didn't have any reason to add hardware-style external interrupts <rkeene>But the code is really trivial :-D <muurkha>async I/O is handy for interactive computations like compiling a program while your text editor remains responsive, and hardware interrupts can be useful there <muurkha>the alternative in that case is to poll for keyboard I/O inside each of the compiler's inner loops or to have some kind of multithreading <rkeene>Sure, and a set of programmable timers and a clock would be useful for that <muurkha>I think the register-interrupt-vector approach is a very nice way of adding a subroutine mechanism to BF <muurkha>yeah, although you really only need a timer interrupt to support time-sharing between multiple background tasks, and you only need one <rkeene>Trivial to add, the goal here was to make programs not a whole system so I left out pretty much everything I've written in other VMs in the past <muurkha>it's not as intellectually interesting as sf <rkeene>Next is to add SF support to ELVM, then compile TCC using ELVM ;-) <achaninja>does anyone know the status of mescc amd64 support? <stikonas>achaninja: it might be more of an issue of patching tcc and not mescc <achaninja>i am trying to compile a simple printf with mescc atm <achaninja>I can see printf is not included in libc.a for some reason <stikonas>although strange, we do build quite a bit of stuff <stikonas>libcmini is probably enough for mes itself <achaninja>that must be the case, trying to work out how to get the libc used to build tcc instead <fossy>yes, libcmini is not sufficient <fossy>you need to build libc+gnu version iirc <achaninja>any idea how to tell mescc to use that file? <stikonas>just updating checksums due to libc changes <stikonas>and these early checksums are not automated <fossy>not tooo many of those though <stikonas>well, until recently even later checksums were manual <achaninja>btw, was mes originally written in assembly? <achaninja>I wonder how it came to be that there are C compilers in assembly <achaninja>I am guessing that is what turned out to be the most practical for whatever reason <fossy>no, mes was not originally written in assembly <fossy>oriansj wrote cc_x86 in assembly, which is used for M2-Planet, which is used for mes <fossy>that is the path that happened to take shape, essentially <achaninja>I suppose its slightly unusual in that it goes c -> lisp -> c again <achaninja>oriansj: would it be possible to generate a tarball for stage0 releases instead of relying on github tarballs? <achaninja>unless they are published somewhere I haven't seen <achaninja>i think github just generates them with git archive | some-gzip-version-we-dont-know <achaninja>Also I suppose github does not include the submodules <muurkha>github release tarballs are in many cases just random files you upload when you create the release <achaninja>I suppose one may want to cross reference them with git <muurkha>GitHub made no attempt to produce that these build artifacts themselves or to verify them against the corresponding source code <achaninja>I trust that more than github tbh - for example if you signed it with gpg and put the signature on your own domain <muurkha>sure, that's plausible, but it definitely doesn't give you reproducibility of the binary tarball <muurkha>unless the individual author has made the effort to do it (I didn't) <muurkha>they *did* create the source tarball and zip file from the tag <achaninja>yes, however it doesn't include any of the submodules <muurkha>right, though in this case I didn't have any <muurkha>didn't occur to me that git archive strips out the submodule commit hashes but I guess it does <achaninja>when I downloaded the github tarball it didn't even have the files <muurkha>it makes sense that git submodule information would be missing <achaninja>the problem is the package manager I am using currently prefers tarballs <achaninja>I had some thoughts about creating a 'canonical tar' format that is reproducible <achaninja>and being able to canonicalize input tarballs and then hash the result <achaninja>like timestamps and different compression algorithms <achaninja>yeah, my other idea was to provide a web url that goes <achaninja>so you can just download canonicalized tars that are ready to have their hashes checked <achaninja>however I think a new format is largely unnecessary <fossy>i don't think a website that does that would be really acceptable in bootstrapping, but the idea is generally a good one <achaninja>but if they were instead canonical tars they can be verified <achaninja>fossy: the website is just convenience since if you already have the hash <achaninja>One problem is I didn't know how to choose a canonical gzip compressor <achaninja>I could just select an arbitrary release of gnu gzip for example <fossy>well, yes, but you're still trusting that someone has verified that the canonicalizer does not tamper with sources <fossy>if you canonicalise on the fly then you don't have to trust that <fossy>do gzip outputs differ from version to version these days? <achaninja>since make uses mtimes sometimes to check if it must regenerate a file <achaninja>my design for canonical tar was posix tar format with guaranteed sorting, and a fixed uid and mtime <muurkha>I think you'd want to set all the mtimes to 0, yeah <muurkha>normally you don't want to include things in your tarball that make knows how to generate <achaninja>for example often perl is a dependency, but only for info files <achaninja>and make checks if the info files are out of date <achaninja>but yeah, maybe that can be solved other ways if you want to <muurkha>I think you can pare away those epicycles <achaninja>I think overall it will be nice to not have to wrangle so many tar options <oriansj>achaninja: well the problem with secure and reliable source distribution is that is a much bigger problem than just a single tarball. So I left it a something for someone else to solve <achaninja>thats ok, for now I'm checking in a copy os stage0-posix into my package tree <achaninja>my package tree I'm working on is attempting to distribute source over bittorrent and ipfs <achaninja>however I can just make my own trusted tarball releases <achaninja>assert fail: eval/apply unknown continuation Segmentation fault (core dumped) <achaninja>./bin/mes --no-auto-compile -L module -e main scripts/mescc.scm -I include -v -S scaffold/exit-42.c <achaninja>hmm no, I wonder if the example in the readme is out of date <Hagfish>achaninja: great idea to use bittorrent and ipfs. anything that removes SPOFs and makes bootstrapping resilient is good to see <muurkha>Hagfish: is ipfs free from SPOFs? I thought there was like a centralized blacklist of badthink files or something <muurkha>different regimes use different terms for it: "subversive literature", "fake news", "rumors that undermine social stability", "copyright infringement", "degenerate literature" <pabs3>muurkha: ah, yesterday I *didn't* actually paste the rude version to HN! what you saw was the less-rude version <achaninja>muurkha: I am trying to avoid ipfs mainly because <achaninja>i don't like how it only has a single implementation <achaninja>but it does have some useful properties that bittorrent doesn't <achaninja>I mainly want to let people keep hosting their own code if they want <achaninja>it is super annoying when a build gets interupted by a missing server, its happened to me before <muurkha>pabs3: yes, I suppose it wasn't the most inflammatory version ;) <achaninja>the master release does not seem to be running for me <achaninja>I did an ls mes/modules and saw nyacc and assumed it was there <achaninja>janus: I spoke too soon, it now works fine with guile <janneke>well, celebrate each (little) success! <achaninja>its fun, im gonna attempt to compile (parts of) another C compiler <achaninja>I can't help but get the feeling the invocation in the mes-m2 repository is not right <achaninja>but its also highly likely I did something else wrong <achaninja>I think theres a mistake in the readme for m2-mes <achaninja>janneke: I guess that is normal for the 32bit compiler <janneke>achaninja: dunno, not sure what you're doing <achaninja>adding -m 64 allowed me to handle int64_t but I got a different error <achaninja>I'm gonna try to use creduce to find a minimal C file that produces the error but still works under gcc <janneke>note that x86_64 support is still experimental in mes, iow, it cannot build tinycc correctly <achaninja>I can also try to patch cproc to avoid 64 bit variables <janneke>a guile binary is needed for the guix driver, and it's also used to run gash and gash-utils ***attila_lendvai_ is now known as attila_lendvai
<achaninja>is there a configure flag for mescc that tells it what arch it should be building? <achaninja>I'm on an x86-64 platform but want it to build a 32 bit libc+tcc <achaninja>it seems to be just building the 64 bit version <fossy>hm, can't you have uint64s on 32-bit? <fossy>mes def has long long support which is standardised as >=64 bits <achaninja>it generated the same assembly for long long as it did for int <achaninja>the tcc codebase does mention int64 but maybe not in a code path the bootstrap uses, not really sure tbh <stikonas>are you looking at tc 0.9.26 with janneke's patches? ***malvo_ is now known as malvo
<vagrantc>is mescc-tools M2libc unchanged from mescc-tools 1.3 to 1.4.0 ? <vagrantc>never managed to wrap my head around git submodules *janneke set: git config diff.submodule diff <janneke>and then: git diff Release_1.3 Release_1.4.0 -- M2libc <janneke>while this gives a diff: git diff Release_1.2.0~10 Release_1.2.0 -- M2libc <stikonas[m]>stage0-posix doesn't use submodule from mescc-tools/M2libc anyway <vagrantc>does mescc-tools build without the submodule? *vagrantc still uses antiquated technology that builds from tarballs :) <vagrantc>answered own question... nope, doesn';t build :) *janneke has been creating tarballs for all those <janneke>the guix bootstrap needs tarballs too, of course <vagrantc>yeah, bootstrapping git seems a bit of a dangerous idea <bauen1>there's this tutorial on implementing git from scratch in python, so not that far fetched <vagrantc>that seems to have an even larger bootstrapping chain... <Hagfish>lol, don't worry, there's a way of bootstrapping Python from Rust... ;-) <bauen1>not saying we should use that tutorial, but that it can be done without major issues *janneke thinks we're making amazing progres ***stikonas_ is now known as stikonas
<stikonas>well, if you don't want to bootstrap git, you'll still have to bootstrap tar and gz <stikonas>you actually need to start with some unpacked files <stikonas>though having to get it with git is not ideal <stikonas>but tar.gz in some sense is not ideal either <stikonas>but at least this is only a problem for stage0-posix and anything else can be built from tarballs as stage0-posix contains untar and ungz <janneke>yeah, anyway it's not a problem worth focussing on right now, i think <Hagfish>janneke: i'm sorry if my paranoid worry sounded cruel. when i think rationally about it, i too am in awe at how much progress has been made <Hagfish>i think i just hadn't thought about the issue of bootstrapping version control before, and for a moment the whole problem looked fractal, but that just shows my lack of perspective <stikonas>well, stage0-posix would always be somewhat cyclic, you can't completely bootstrap it and there will always be issues like that. You can only avoid them in baremetal bootstrap. <stikonas>but obviously baremetal bootstrap is less portable and harder <stikonas>but if you do baremetal bootstrap, bootstrapping version control is non-issue <stikonas>you can start with some sources printed on paper <bauen1>i'd argue that how the sources are obtained isn't all that interesting as long as you can audit / view / edit / hash them