<oriansj>gbrlwck: well to replace current computing stacks with equal power would require billion dollar lithography machines. But 1 micrometer processes do appear to be available right now; which with refinement should enable 32/64 processors and enough RAM to build a trusted root and to power machines needed for more refined processes. <pabs3>Hagfish: people like bunnie might be good to partner with on the hardware side, he is already thinking about hardware trust and has done talks about hardware supply chain attacks <pabs3>he is pretty famous in the tech world too <gbrlwck>oriansj: this sounds interesting! do you have any links/literature? <oriansj>and I aam probably missing a bunch more ***smartin1 is now known as smartin
***dongcarl2 is now known as dongcarl
<riv>hm it boasts 4k lines, that's about the same as mine <riv>oh not 4k lines, 4k binary? that's different to mine <plantman>Hi. I wrote a simplified (low dependancy) compiler, which is currently just does a source to source trans. <riv>what source target and host language <plantman>changes "import" with "using", changes "boolean" with "bool" <plantman>changes how classes specify extends and impliments <plantman>code that does the actual trans is about 1000 lines <plantman>changes an abscense of modifider to "internal" <stikonas>the whole M2_Planet's cc_core file that does C parsing and multiarch (knight, amd64, x86, risc-v, arm/arm64) compilation is about 2600 lines <plantman>like how do you do that much stuff in 2600 lines? wow <gbrlwck>did not check myself, but i guess the figure might be a bit higher than that? but honestly: LOC is not the best measure for complexity/density. the goal in stage0 (and such) is absolute minimalism and introspectability <plantman>on stage0's savannah project site it shows that it is "alpha", but it works? <plantman>All I'd like to know is, if it works currently. <gbrlwck>well, stage0-posix (main repo is oriansj's on github) works for some architectures <gbrlwck>so i've been able to bootstrap from /nothing/ up to GNU MES (on riscv64) <gbrlwck>then the answer to your question is: yes ;) <stikonas>plantman: I wrote most of the risc-v support for stage0-posix *without* risc-v board <stikonas>and only a very minor tweak was later needed to make it run on real hw <stikonas>but yes, super small line count is not necesserily a goal <plantman>I'd like to contribute by having easy-to-understand and easy-to-use in some later stages <stikonas>well, for C stages, M2-Mesoplanet might help with making M2-Planet easier to use <stikonas>(since it spawns assembler and linker automatically) <gbrlwck>it's like the "gcc" frontend for out bootstrappable toolchain <stikonas>M2-Mesoplanet is C preprocessor (up to now M2-Planet had some C preprocessor but it's getting big, so it's starting to make sense to continue separately) <stikonas>but I don't know if anyting can be done about that <stikonas>you just need to setup quite a few environmental variables <plantman>People know about LFS, but I dont think they know about live-bootstrap. <stikonas>although not so tiny if you compare to e.g. M2-Planet (which is 1/10 of a size) <plantman>i'm familiar with tinycc, I think I forgot that it was renamed from tcc to tinycc by bellard <stikonas>plantman: it's mostly 1/10 because of missing features <plantman>I was amazed that tinycc compiled a modified linux kernel, in super fast time <stikonas>some of it would be good to add, then M2-Planet would be bigger <stikonas>but since it's still written in cc_* subset, it will be bootstrappable <stikonas>plantman: fossy had a lot of trouble building linux kernel, right now we only build linux kernel in live-bootstrap once we have gcc <plantman>Yes, the boot-strap-ability, its good for ease of use, and technical ease of use <stikonas>so fossy was not able to get tcc to build linux kernel in live-bootstrap... <plantman>I never understood the explanation of why they used extensions and such, to make linux kernel more cross platform. <stikonas>I don't remember what was actually difficult with tcc, but it might not even be linux kernel itself but kexec-tools <plantman>got to go, but it was really nice meeting you nice people, and talking about #bootstrappable <gbrlwck>plantman: you're welcome (to joint the bootstrappable work force ;) <gbrlwck>stikonas: have you been able to check whether you can compile crt1.c with mescc? <oriansj>hmmm I might want to add a --hex2 flag in get_machine to match the one we already have with --blood <oriansj>that way test1000 can be a bootstrap build and a self-host which should have identical outputs ***qyliss_ is now known as qyliss
<oriansj>ok, I've been looking more into properly doing #include and it looks ugly <plantman>That's a major reason why I liked java for a while. Condidtional compilation is such a prob. <stikonas>yeah, #include and macro functions are two big things that we need to implement... <stikonas>and macro functions are also non-trivial <stikonas>I have wip branch but it needs more work <oriansj>well #include we can punt for a little while <oriansj>but proper macro functions are essential if we want to build upstream Mes.c <muurkha>it's the semantics of #include that are a mess <oriansj>muurkha: feel free to make a pull request <oriansj>and we can restrict the semantics of #include we are willing to accept <oriansj>So extra easy for anyone who wants to be responsible for it <plantman>How about for a bootstrapping compiler, not use macro functions at all. <oriansj>plantman: upstream GNU Mes uses macros and it is a lisp interpreter <oriansj>So we either need to have upstream drop the macros from the main branch, add support for macros or do the M3 work to skip the need for GNU Mes entirely <oriansj>currently adding support for Macros seems to be the path of least work <muurkha>hmm, I think the core of adding #include to cc_x86.M1 would involve changing fgetc to have an extra conditional which, if it hits EOF (!-4), pops the previous input file from an input file stack, unless empty, and retries <oriansj>muurkha: no one here would be adding #include to cc_* <oriansj>#include support would be added to M2-Mesoplanet <muurkha>that's exactly the kind of thing I wanted to find out by asking :) <oriansj>M2-Mesoplanet is a stand-alone C preprocessor that by default spawns M2-Planet, blood-elf, M1 and Hex2 to compile the input C source into a Binary in a single step <oriansj>and the #include functionality is to enable one to be able to do: M2-Mesoplanet -f foo.c -o foo instead of doing M2-Mesoplanet -f M2libc/stdio.c -f.... -f foo.c -o foo <muurkha>heh, there's already an "implementation" of #include at cc_macro.c:656 <muurkha>it conditionally sets the STDIO_USED flag :) <oriansj>muurkha: that is correct, it doesn't yet do the work required to remove the need for manually doing -f file for all of the files that #include is supposed to automatically solve <oriansj>So our implementation is just ignore it right now <oriansj>however making it actually fully useful would probably make its use much easier <muurkha>so I'd have to change that and the implementation of grab_byte in cc_reader.c:27 <muurkha>add a stack of `input` and `line` pairs <oriansj>and I just pushed a commit with a bootstrap script to give anyone who wants to finish the test1000 self-host test a quick start; while I add functionality to get_machine <oriansj>and some custom logic to know <foo.h> probably means to load $M2libc/foo.c or $M2libc/$ARCH/foo.c <oriansj>and to process all of the #includes in those files as well <oriansj>and the struct used in that linked list will also need state tracking so we don't do duplicate loads of files as that would cause issues in the build when we started passing things to M2-Planet <oriansj>and a way of passing filenames to blocks of C code via the tempfiles to enable M2-Planet to make useful error messages will probably needed too <muurkha>well, processing the includes in those files falls out automatically <oriansj>I was thinking \x127 $FILENAME to make it a trivial add in M2-Planet's cc_reader.c <muurkha>duplicate loads of files are normally taken care of by #ifndef __CRAP__ / #define __CRAP__ ... / #endif <muurkha>or just by not doing recursive includes <muurkha>that is, it's not the preprocessor's responsibility <oriansj>but shouldn't be complicated updates to add <muurkha>oh, because it does unprotected includes now? <oriansj>just straight C blocks of code as it was just hacked together and slowly growing in functionality <muurkha>but yeah you'd definitely need to have an include path, which means a loop over directories, and you'd want to point to the successful filename in the input-source struct <oriansj>right now we assume ./M2libc unless an override by setting an enviromental variable; no search required <muurkha>well, you said "$M2libc/foo.c or $M2libc/$ARCH/foo.c" <stikonas>oriansj: can we not do $M2libc/$ARCH/foo.c via #ifdefs and further includes? <stikonas>then no need to have extra logic to find 2 paths <oriansj>stikonas: yes that is entirely possible <oriansj>the only change possibly needed might be in the architecture specific $M2libc/$ARCH/bootstrap.c <oriansj>correction the $M2libc/$ARCH/$DISTRO/bootstrap.c file <oriansj>and the newly enhanced get_machine is now up <oriansj>get_machine --blood, get_machine --hex2 and get_machine --endian will now provide enough information for any script doing an M2-Planet build <oriansj>kaem doesn't yet support that but that shouldn't be an issue for M2-Mesoplanet's tests <stikonas[m]>Well, it can be added to kaem too, but then it's yet another syscall... <oriansj>whenever someone gets around to that <stikonas>well, kaem can deal with arches even without get_machine <muurkha>you don't actually need dup2 if you have dup <stikonas>anyway, we already define ARCH variable in live-bootstrap <stikonas>so doing arch specific stuff is possible <oriansj>yes but I was talking about the variable=$(get_machine --blood) sort of pattern <oriansj>also doing sha256sum /test/test1000/tmp/proof > /test/test1000/tmp/proof.answer also isn't supported by kaem yet <stikonas>no, but you would usually do that for development only 