This was created as part of the Bootstrappable Builds project to go from an MBR of machine code plus a ton of source all the way up to a full distro. https://bootstrappable.org/
I would love to get guided through how they wrote this.
21–30 of 79 posts
This was created as part of the Bootstrappable Builds project to go from an MBR of machine code plus a ton of source all the way up to a full distro. https://bootstrappable.org/
I would love to get guided through how they wrote this.
Earlier quoted context omitted.
A recent comment from LWN on that note: https://lwn.net/Articles/893608/ I asked about this on their IRC channel and got this response from oriansj: Well we did bootstrap a FORTH from hex: https://github.com/oriansj/stage0/blob/master/stage2/forth.s and we did bootstrap a garbage collecting Lisp from hex: https://github.com/oriansj/stage0/blob/master/stage2/lisp.s but if you notice: https://github.com/oriansj/stage0/…
> but if you notice: https://github.com/oriansj/stage0/blob/master/stage2/cc_x86 .... > writing a C compiler in assembly that supports structs, unions, arrays, inline assembly and a bunch more was done in less than 24 hours by an inexperienced C programmer. That’s a weird commit comment ( “Implemented C version of cc_knight-native” ) for a commit that adds a C compiler. Also, how do you conclude from that that it too…
I read that as "implement a C version of a C compiler for Knight's Landing processors". I might be reading too much into it, though.
I'm surprised they wrote a minimal C compiler in assembly rather than any LISP dialects, then make a C compiler in LISP
> I'm surprised they wrote a minimal C compiler in assembly rather than any LISP dialects, then make a C compiler in LISP I recommend you check out the author's GitHub page. It includes Forth and Lisp projects, explains why C was a success while those projects failed, and challenges any Forth and Lisp fan to actually substantiate their baseless claims with actual work instead of pushing beliefs that don't have any be…
Earlier quoted context omitted.
A recent comment from LWN on that note: https://lwn.net/Articles/893608/ I asked about this on their IRC channel and got this response from oriansj: Well we did bootstrap a FORTH from hex: https://github.com/oriansj/stage0/blob/master/stage2/forth.s and we did bootstrap a garbage collecting Lisp from hex: https://github.com/oriansj/stage0/blob/master/stage2/lisp.s but if you notice: https://github.com/oriansj/stage0/…
That an inexperienced C programmer wrote what appears to be 5000 lines of assembly in 24 hours implementing a fully working C compiler seems... a rather extraordinary claim. The file size of around 130K would indicate typing non-stop for 24 hours at something like 100 characters per minute.
I'm surprised they wrote a minimal C compiler in assembly rather than any LISP dialects, then make a C compiler in LISP
> I'm surprised they wrote a minimal C compiler in assembly rather than any LISP dialects, then make a C compiler in LISP I recommend you check out the author's GitHub page. It includes Forth and Lisp projects, explains why C was a success while those projects failed, and challenges any Forth and Lisp fan to actually substantiate their baseless claims with actual work instead of pushing beliefs that don't have any be…
I think that the takeaway is familiarity trumps technical 'superiority'. That said I don't know why having a working GC for Lisp is that important because typically you'd use Lisp to compile your C-compiler so memory efficiency doesn't really matter..
"Minimal" being almost 5KLOC, sheesh. Actually, I'm surprised that a C compiler fits in that space. Also: --- Goal This is a set of manually created hex programs in a Cthulhu Path to madness fashion. Which only have the goal of creating a bootstrapping path to a C compiler capable of compiling GCC, with only the explicit requirement of a single 1 KByte binary or less.
Earlier quoted context omitted.
I would think that making a minimal forth or lisp would be the better path towards that goal, then use that to bootstrap a c compiler.
A recent comment from LWN on that note: https://lwn.net/Articles/893608/ I asked about this on their IRC channel and got this response from oriansj: Well we did bootstrap a FORTH from hex: https://github.com/oriansj/stage0/blob/master/stage2/forth.s and we did bootstrap a garbage collecting Lisp from hex: https://github.com/oriansj/stage0/blob/master/stage2/lisp.s but if you notice: https://github.com/oriansj/stage0/…
While everyone asks about lisp or forth for this task, I have to wonder what one has to leave out of C to make it "minimal" enough for this task. The subset of features left out might teach us something about the language.
Trusting trust all the way down: How do you trust your assembler to output the exact machine code corresponding to the source? How do you trust whatever program you might use to do the validation? Ok, let's skip the assembler and write machine code directly. How do you trust the program you use to write that machine code? How do you even trust the firmware will execute your machine code in the way you intend?