<OriansJ>fossy: your coreutils work, it gives me an idea for reducing the bootstrapping time and complexity but it would force me to backtrack a little bit on M2-Planet and mescc-tools. <fossy>OriansJ: whats that? Coreutils in M2-Planet? <OriansJ>no but what if we converted TCC to M2-Planet's C subset? <fossy>I have toyed with the idea of replacing mes-m2 + gash with tcc + kaem <OriansJ>actually I was thinking of some enhancements from M2-Planet that TCC could really need. The first of which is the C compiler outputing assembly and having a seperate assembler and linker <OriansJ>So, I'd first have to create/convert a proper assembler/linker written in M2-Planet's subset <OriansJ>as M1 and hex2 would need serious changes to support some of the more complex elf functionality that bauen1 needs for his kernel <OriansJ>which by breaking TCC into a more M2-Planet style Compiler, I could trivially get it to run on bare metal <OriansJ>Then the bootstrap path would evolve into one where TCC becomes a redundant step. <OriansJ>So by simply freezing M1+hex2 and starting fresh with a proper Assembler (possibly found and converted to M2-Planet C) we skip alot of duplicate work, MesCC gains the ability to just match output with GCC -S and not deal with ELF headers anymore <OriansJ>That should significantly simplify MesCC's porting to new architectures <OriansJ>It has some significant advantages but requires me to do a significant amount of work with no directly useful results for a while. Not to mention would delay the mes-m2 work. <OriansJ>It would also enable a "cheat" bootstrap for janneke, as TCC could compile Guile if I remember correctly. <OriansJ>which would reduce the guile+MesCC->GCC bootstrap down to only a single generated file in guile. <OriansJ>but because of DDC, we have something to validate guix's bootstrap root of just guile. <OriansJ>But when we choose to do a proper bootstrap for guile, we simply finish mes-m2 <OriansJ>First 2 things that need to be done for that option 1) Find a proper assembler written in C. 2) Figure out how to statically compile TCC with a single GCC command with no linking. <fossy>OriansJ: We would also need to ensure Mes C Library can be compiled with M2-Planet. <fossy>TinyCC require Mes C Library <fossy>Why do you think we need a new assembler and linker? <fossy>I haven't tried getting Guile to compile with TCC. <fossy>in addition we need a coreutils implementation - potentially pre-coreutils (textutils and family) or busybox? <fossy>Actually no we don't if we script up my coreutils build for TinyCC. <fossy>(so it dosen't depend on make). <fossy>So, 1. Mes C library in M2-Planet. 2. TinyCC in M2-Planet. 3. Coreutils scripted build in kaem, ideally without need for configure script (because it is a 40k line configure script with many strange shell functions that I couldnt even do with gash, had to do bash first). All that would need to be generated there would be config.h. Then we can compile bash 2.09b and have a proper sh. <fossy>That would need to be scripted without make too. <fossy>I don't feel like getting kaem into a state to run these stupid configure scripts is very dobale for me without a ton of work. I reckon it would take me at least 12 months. <OriansJ>fossy: because getting a proper assembler and linker will make the work considerably easier <OriansJ>2) proper assembler and linkers make implementing specializers easier <OriansJ>3) specializers make porting to new architectures much faster and easier (GCC uses them to great effect) <OriansJ>They take the output generic assembly of a C compiler and specialize it to work on a target architecture. <OriansJ>So instead of the big messy logic in M2-Planet, a single generic assembly is output from the C compiler. <fossy>Because TinyCC is a mess, I wonder if older versions (less messy, less code) could be used? <fossy>MesCC uses 0.9.26 - the latest is 0.9.27. <OriansJ>Then I'll hard fork TCC into (lets just call it) M3-Star and convert it to use the new assembler/linker combo we find (or make) (lets just call it M3-moon) <fossy>OriansJ: I suggest we use 0.9.26 TCC or earlier <OriansJ>well converting TCC to output just generic assembly will significantly reduce the size of its code base <fossy>0.9.27 is significantly more complex, and 0.9.26 is the target MesCC uses currently. <OriansJ>Specializers will embed only architecture specific translations <fossy>Well, have a think about it, if you want to go ahead with it <fossy>and if you do LMK if I can help <OriansJ>Well, I am going to have to do some testing to see how reasonable of a plan it is <fossy>Let's call this idea the Scheme-less bootstrap :P <fossy>We had Scheme-only now we are thinking Scheme-less <OriansJ>just need to spot a good cross platform assembler/linker written in C <fossy>IMHO i think this is a plan that you will get more help on than Mes-M2, because there are no other programmers here that are so good at both M2-Planet C and Scheme, as well as interpreters. <OriansJ>well C programmers are alot easier to find than scheme programmers <xentrac>not sure the difference is very large if we're talking about good programmers <OriansJ>however dddddd is going great work in M2-Planet and scheme <OriansJ>xentrac: actually not just good programmers but also programmers willing to work on bootstrapping work. It is a very small population. <OriansJ>basically a subset of the people here. <OriansJ>xentrac: possibly but we would need to find them <OriansJ>however getting 2 people to work on a scheme interpreter at the same time is a much harder problem than getting 2+ people working on a C compiler at the same time. <fossy>oh, yeah dddddd is great at both too <fossy>xentrac: I mean those that are well versed in both <fossy>OriansJ: let me clarify your plan is to find/make a new assembler / linker and make tinycc use it? <fossy>porting mes c library and tinycc to m2-planet? <fossy>so m2-planet will be superseded by tinycc fork? <OriansJ>fossy: it'll become the step after M2-Planet in the bootstrap <OriansJ>I can also remove it's need for a libc <fossy>so m2-planet will still exist in the bootstrap <OriansJ>yep and the new M3-star will be able to build glibc and gcc directly <fossy>if you can remove the need for a libc that would work <fossy>OriansJ: not quite, mes c library would still be nessrcary <fossy>for things like bash and the like that we need before glibc and gcc <OriansJ>fossy: fine the libc would become a _start function and that is it <fossy>what would bash (for eg) use? <fossy>how do we build glibc though? we need things like make and coreutils for that which require a libc <OriansJ>xentrac: perhaps we should simply ask the question. Who here is willing to work on mes-m2 and who is willing to help on this currently discussed crazy plan of mine. <OriansJ>fossy: we simply figure out a single GCC command that could build glibc <OriansJ>no need for make or coreutils if we know exactly how to compile something <fossy>I think it would probably have to be multiple commands but still we can script it up without configure or make <OriansJ>fossy: and kaem can handle that with ease <fossy>personally my skills are more tuned to the latter, the currently discussed crazy plan <fossy>as long as we dont use configure :p <fossy>and then from the scripted builds of gcc, glibc, make and bash we can go on rather easily <OriansJ>fossy: what next requiring autotools to build a bootstrap piece? <fossy>all I mean is that I dont think its feasible for kaem to run configure scripts <OriansJ>fossy: small joke. Because we are bootstrapping, we can control everything and require no build tools beyound kaem <OriansJ>instead of using configure to figure out what we have, we already know because we put it there <fossy>for the first gcc and glibc thats right we dont <fossy>for later stages its probably better, so we can avoid scripting every build <fossy>Before you commit to this plan carefully think of the alternative mes m2. How much work would we need to do to get it to run mescc? <dddddd>hi! I'm just finishing the long and wildy insteresting log (: <dddddd>First of all, thanks for the kind words (I'm not that well versed in anything but it seems I can fake it :P). <OriansJ>fossy: well thus far janneke estimated it'll take several months before mes-m2 is ready to run MesCC. <dddddd>I'm +1 on a C path. I was willing to work on mes-m2 because that seemed the current and most important plan; but if the new season is about C, so it be! <OriansJ>considerable more work to be able to bootstrap guile and guix <dddddd>I still have to digest the details, one read is not enough. <fossy>same, I have a vague understanding of the idea but not quite up to speed. <fossy>I vote for c path in that caee <dddddd>IR instead of the M2-Planet conditional maze sounds great. <OriansJ>dddddd: and if we find simple core versions of specializers, we can backport them to M2-Planet/cc_*.s <OriansJ>M3-moon for the assembler/linker and M3-Star for the C compiler work <OriansJ>as the assembler/linker should be smaller than M2-Planet <OriansJ>and The C compiler should be much larger than M2-Planet <dddddd>By M2-Planet freeze you mean only new archs (and no more features, as in no v2.0 that was on the table), right? <OriansJ>dddddd: yes as M3-Star would be taking the place of a the future v2.x M2-Planet <dddddd>nitpicking as usual: why moon (lower case) and Star (upper)!? <OriansJ>it'll be M3-Moon to match the naming standard of M2-Planet <fossy>So, if we go ahead, I will continue to build gcc-seed as if tinycc and mescc was going to be M3-Star <dddddd>The metaphor of the sizes is kind of nice but a bit confusing, as the moon seems to go with the planet (not with the star). We can use those term as working names for now but I think we need to find something else, long term. *dddddd ends the bikeshedding <OriansJ>fossy: well in gcc-seed, essentially it would be like a statically built TCC appeared right after M2-Planet <OriansJ>smaller than planet but orbits the Star <OriansJ>although before we can go that route dddddd will probably need to do a slow-utils release for janneke so that guix can reduce down to just guile. <dddddd>sure, M1.scm goes first from my side, parallel thinking about the new universe objects notwithstanding (; <dddddd>To be honest, I didn't look at the rest of the pieces (blood-elf.scm, hex2.scm) but I guess there's at least some clean-up to do (maybe post-release). Are those working as intended, OriansJ? <fossy>and then statically built gcc and glibc straight after that <fossy>OriansJ: wait, what libc will gcc use, since currently glibc is build with gcc <OriansJ>dddddd: they are working good enough to give janneke what he needs, there however are things that could be improved in them. <OriansJ>fossy: good question, let me think about that. <OriansJ>as we need to know what libcs that TCC can build <OriansJ>and depending on which one we find, could we eliminate steps in the GCC bootstrap <fossy>I think we could potentially look at for the time being using an earlier verison of glibc <OriansJ>thank you fossy for looking into that for me; but do try to find the most maintained libc that TCC can compile. It'll save us effort long term. <fossy>there's quite a few libcs out there <OriansJ>fossy: lets first find the ones being actively developed, check against tcc. then we can filter down to the best option for us based on the number of active developers and how willing they are to assist in the bootstrap effort. <fossy>had another thought... won't most libcs require a libc to start off with <OriansJ>fossy: we are just going to hit that bridge when we get to it <OriansJ>I can break alot of bootstrapping loops when I need to but let us hope that libc developers are not completely insane in regards to bootstrapping. <fossy>janneke: is this true of glibc <janneke>there are loops everywhere, you need to pick a path and make it work <fossy>janneke: in the current bootstrap path glibc needs mes c library right <janneke>fossy: that statement is very strong and non-specific; if i were to say: in the current bootstrap we build mes c library long before we build glibc; then yes that's true <janneke>tcc does not run without mes c lib, so ... i don't eacctly know what the dependencies are after that <janneke>i split the mes c library in 4 parts: mini, mes, tcc and gnu <janneke>i was expecting OriansJ to add one split for M2 <janneke>tcc needs, obviously, only the tcc variant of mes c lib <janneke>and different historical version of TAR have different requirements on the `gnu' variant of mes c lib <janneke>but, now we have tar form gash utils <damo22>ideally id like to burn a couple of trusted binaries into my bios and use those to bootstrap my system in an 'emergency' <damo22>i think baking them in to the firmware and being able to reproducibly build them later solves the initial bootstrap chicken/egg problem ***jelle is now known as jly
***jly is now known as jelle
***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
***reepca` is now known as reepca
<bauen1>before i start porting a libc to my kernel, are there any better options ? <bauen1>my current plan would be to port musl <bauen1>while musl is linux-only it is quite complete and also quite easy to port <bauen1>for the first iteration of myunix i actually went and used newlib, but it turns out newlib doesn't really follow the standard closely and it's a mess to port <janneke>(tongue in cheeck) we all write our own libc's here ;-) <bauen1>lol writing a somwhat standards confomring libc is a project bigger than writing a kernel ... <janneke>haha, some of us care more about staying close to the posix/libc alphabet than others, but many of us had to prioritize bootstrappability over compliance/comformance <janneke>bauen1: for example, the mes c library can be built in a 'mini' variant, that has only crt1, write and exit ***vup2 is now known as vup
***warren_ is now known as warren
***main1 is now known as main