<OriansJ>although I am confused how he "looked" at stage0 and didn't notice my email address in the README (specifically the "If you wish to contribute" section); but it is always possible he never saw a link to the stage0 source code. <OriansJ>or just never bothered to look at the readme. <fossy>come on tinycc.... i specifically moved you out of /usr <fossy>open("/usr/lib/crt1.o", O_RDONLY) = -1 ENOENT (No such file or directory) <OriansJ>somedays I wonder if I have the only easy to work with C compiler. <OriansJ>and other days I wish I spent more time building a much better assembler. <fossy>has anyone ever pursued bootstrapping via microcontrollers? <fossy>microcontrollers imo would be an interesting starting point because they have minimal/no binary seeds <xentrac>fossy: I think that's a very reasonable approach because they also have minimal space for backdoors <xentrac>as Aineko said in Accelerand, "I've bootstrapped myself starting from a clock radio controller" <fossy>OriansJ: well I got the idea from collapseos <fossy>found out about collapseos yesterday <fossy>interesting propersirion, im not sure about the Why but opens up quite a few possibilities in other areas <OriansJ>well there is nothing from preventing someone from implementing the stage0 steps in 8051 assembly or z80 or PIC16 or 6502 as all the steps up to M2-Planet can run in 8KB <OriansJ>It just requires someone to take the time to do the work (i'll even merge it into mescc-tools-seed and stage0 if someone does the work) <OriansJ>I've also been looking into how to get M2-Planet to work in 32KB of RAM. <DKordic>Oddly enough ARM-Cortex is _binary_ compatible from M to A. ***vagrantc_ is now known as vagrantc
<fossy>while trying to fix stupid tinycc <bauen1>fossy: i've build a 65816 (16-bit ~~version~~ extension) based sbc and i've started to write a code generator for '816 native code for 8cc <bauen1>so technically it should be possible at some point to have a self-hosting 8cc <bauen1>it currently generates assembler code so to bootstrap it you would need a c compiler written in assembly and a simple assembler ***reepca`` is now known as reepca
<OriansJ>bauen1: we already have an entire family of C compilers written in assembly and boostrapped from hex for 3 different architectures. <OriansJ>It'll only take about a day to port to the 65816, assuming one is comfortable with 65816 assembly <Hagfish>that sounds really cool. keep up the great work, booters <fossy>janneke: what was the first mes version to be self hosting? *janneke goes to look at the NEWS <janneke>possibly 0.12; NEWS says it can "compile itself" -- but was the result correct? hmm <fossy>interesting, it dosent seem to be very clear, does it <fossy>eh, not a big deal was just interested <janneke>no, that's why i looked; it was a very tricky path that i took <fossy>*** Support compilation with Mescc. <fossy>I remember I had to use it but what for is a good question <fossy>I think I just had to dump it in a directory. <OriansJ>fossy: not actually but nyacc rather a parser generator if I remember correctly (like yacc) <fossy>janneke: mes cannot run gash as of the lastest version, correct? <janneke>i was planning to first do more guile compatibility <janneke>a nyacc-like hack for mes might get us quite far too; shouldn't be too much work <janneke>but i would like to start cleaning up things, rather than making a bigger mess <janneke>we have kind of shown, proven it's a viable path <janneke>now to make the paths worthwile and pleasant to follow <OriansJ>well that is kinda the point of the seperate of MesCC and mes.c; we buy time by reducing the bootstrap to just guile and then we simply grow mes-m2 until we are able to become a drop in replacement for guile in the bootstrap. <OriansJ>Thus solving the Guix, GCC and Guile bootstrap problems all in a single step. <OriansJ>but it also requires mes-m2 to do a hell of alot more than mes.c did.