<stikonas>oh, just noticed that Gentoo ships Autogen with Guile 3.0 patch <stikonas>although Autogen looks really scary, lots of Autogen pre-generated files, not yet sure if they are circular dependencies or not <stikonas>fossy: so it looks to me like Autogen has ciruclar dependencies on pre-generated headers <stikonas>i.e. some headers are generated with Autogen itself <stikonas>so it looks like Autogen is the ultimate boss in the bootstrapping story :( ***Noisytoot is now known as N7t
***N7t is now known as Noisytoot
<oriansj>stikonas: well build systems always tend to be the places where the most build cheating tends to take place. of the 89 parts so far, 39 are just used dealing with bootstrapping the build tools alone. <stikonas>yeah, somehow people think build systems are less important, so cheating is more common <stikonas>we'll see. Maybe we should contact autogen author (Bruce Korb) for any pointers. He must have done that once but it might be lost now <fossy>hm. autogen is super annoying <fossy><stikonas> we'll see. Maybe we should contact autogen author (Bruce Korb) for any pointers. He must have done that once but it might be lost now <fossy>done what? circular pregen header deps? <stikonas[m]>I mean he bootstrapped it once (I guess first autogen didn't have those circular deps) <oriansj>stikonas: the reason usually for why those circular dependencies are inserted secretly is usually shame in regards to how they were implemented and the aurthor not wanting that sort of mess to be associated with them. So they destroy the transistion code needed and we end up having to pull another bison bootstrap. <Hagfish>even if that's not true, i think that as an industry that should be our default assumption, so that developers take extra care to avoid circular dependencies <Hagfish>i should say that i have a lot of respect for people creating useful Free software, and beggars can't be choosers, but i do want them to correctly value the externality of making their software harder to bootstrap <oriansj>Hagfish: well bootstrapping, just like reproduciblity is a value you either have or your don't. And the only way to get people who don't value such things to do such things is to make it easier for them to do so and require them to do so. (Such as Debian's stance on reproducible builds) <oriansj>hmm I wonder if ext2 with a 512byte block size is supported <oriansj>no, it looks like it only goes down to 1024byte blocks. <oriansj>assuming I go with a classical generic MBR that only leaves 446bytes total ***ChanServ sets mode: +o oriansj
<oriansj>With a handful of minor tweaks LEAN might actually be something I could fit in 446bytes and still have 30 sectors of bootstrapping tools before I need to write a superblock. <oriansj>Hagfish: well I want to enable a slow ramp up from a BootOS type root to a minimal POSIX on a uniform standard FileSystem (Without ideally having to create my own filesystem) <Hagfish>i thought i'd check what the limits of human memory are for binary, and was pleased to find it being tracked here: <Hagfish>783 bytes should be enough for anyone :) <oriansj>well x86 MBR can only be 446bytes of bootstrap code (and still be valid or 510bytes to use the entire block) <oriansj>My thought is revise BootOS to just support load and write hex but with a minor twist of specifying start sector and sector count. (as sector 1-30 can be used for the pieces created before LEAN filesystem support is implemented). <oriansj>Make the second program be a more powerful loader that supports LEAN (ext2 or some other filesystem properly) that loads programs after itself and passes arguments on the stack to the programs it loads and export a couple syscalls as interrupts (fgetc, fputc and exit) <Hagfish>i'm not familiar enough with either of those concepts to know how unique that is <oriansj>that is literally what int 0x80 and int 0x21 is in Linux and DOS <oriansj>it then uses the argument you put in the register (probably rax/eax/ax) as in index into a syscall table to lookup the address of the implementation of that functionality and then you do a jump into and the iret would return to the interrupt calling address. <Hagfish>huh, yeah, that makes a bit more sense, thanks <oriansj>but that effectively means both the initial bootstrap and the loader that follows are both Operating systems. One without a real filesystem (just remember where you put stuff) and the other with any filesystem we want as our base filesystem (possibly flagging blocks in it as bad to prevent use because we needed those blocks before it was implemented) <oriansj>So the question quickly becomes given that option is stage0-cpm even a worthwhile idea (worth even the time for me to learn the CP/M or DOS calling conventions and how arguments are passed??) And if so what good reference material exists to minimize the porting time spent? <oriansj>As ultimately only FreeDOS exists in that role and has some complex bootstrapping requirements itself. <oriansj>as it needs gcc 7.2 along with its C++ compiler. <oriansj>stikonas: you are probably quite right, although that is going to take some digging to discover but it does look like they are all written in C (to be compiled by GCC) <stikonas>and I think I fixed non-reproducible build of guile... <stikonas>(there was a deliberate injection of timestamp in Makefile.am) <stikonas>(not that it would help us to get g++)... <stikonas>it might even be easier to build some older pre-autogen g++ and then jump to clang, although that's something I would like to avoid... <oriansj>sometimes easier is less fun than what might be harder. <oriansj>In which case, do what you find more fun. <oriansj>Well, since I have done a scheme, a FORTH, an Assembler, a C compiler, and a libc. I guess the next crazy project will probably have to be a kernel. In either assembly or the M2-Planet C subset. (not sure which yet) <stikonas>assembly might have some blob size advantages...