In principle you could start from hand assembly. Look up “sectorlisp” as a lowest level option. Or you could start from Forth, which is traditionally implemented using very simple methods. The blog post really doesn’t make clear what problem the author is trying to solve. It gives some general description but leaves a lot to be guessed at.
Then there is the question of where the CPU is supposed to come from. Any modern one was designed using lots of mysterious CAD tools. Maybe scrounge a vintage Z80 out of an old Timex-Sinclair or something?
Then there is the question of where the CPU is supposed to come from. Any modern one was designed using lots of mysterious CAD tools. Maybe scrounge a vintage Z80 out of an old Timex-Sinclair or something?
The author doesn’t explain exactly what their interest in bootstrapping is, but the goal is pretty explicit:
So, for me, it would be really nice if there was a Rust compiler that could be bootstrapped from C. Specifically, a Rust compiler that can be bootstrapped from TinyCC, while assuming that there are no tools on the system yet that could be potentially useful.
It seems it would be a lot easier to work on the GCC compiler, and work with others to bootstrap GCC (if it hasn’t already been done). Getting the GCC Rust compiler able to compile some version of rustc probably wouldn’t be that hard, and then you can just use that version to compile up the chain to modern Rust.
Sure, but I guess I don’t really understand the argument. Why would Rust need to be involved earlier in the process? Isn’t the point to have a way to compile rustc completely from source?
I guess it’s cool to have multiple ways to get there, but that project would take way less work and get to the same end goal. It sounds to me like the author is trying to justify a cool project instead of trying to solve a real problem. That’s completely fine, but I think most people would be happy with the mrustc project.
The deeper reasoning is still not explained. C is just terrible for this. Rust is very complicated and writing a new implementation is a big project even in good languages. So using C seems tragic.
I’m going to go further and say that TinyCC isn’t bootstrapped either, since the compiler writer’s thought processes aren’t bootstrapped. You would have to use something like CompCert (i.e. all the reasoning that the programs works is embedded in the program and machine checked) and bootstrap that. It is probably doable, but not as a 1 person hobby project.
Okay. That’s just imposing a different (and at least equally arbitrary, if not moreso) definition of bootstrapping. Why does it matter that the author didn’t explain their “deeper reasoning” for having an interest in bootstrapping, or the Bootstrappable Builds project specifically? If you feel like that project isn’t meeting a sufficient bar for what counts as “bootstrapping”, or that using C as the first high-level language they bootstrap is “tragic”, take it up with that project, I guess.
I will take a look at the bootstrapping project page, but “bootstrappability” is a philosophical notion whose extent depends on what you are trying to get from it. Certainly someone who pursues it should give that some thought and reach a conclusion, rather than just following a recipe on some web site. So that’s the deeper reasoning I felt was missing.
As for C being terrible, well, why would I want to take that up with anyone? It’s simply that we know from 50 years of experience with C that writing bug-free C programs, or noticing the existence of bugs in them, is extremely difficult. If someone decides to use it for bootstrapability anyway, xkcd.com/386 would seem to apply.
collapseos.org (which uses Forth) might also be of some interest, though I think that was another questionable decision. Real transparency and boostrapability requires that the reasoning process be written out and matched up with the code. C does a pretty poor job of that compared to some alternatives.
In principle you could start from hand assembly. Look up “sectorlisp” as a lowest level option. Or you could start from Forth, which is traditionally implemented using very simple methods. The blog post really doesn’t make clear what problem the author is trying to solve. It gives some general description but leaves a lot to be guessed at.
Then there is the question of where the CPU is supposed to come from. Any modern one was designed using lots of mysterious CAD tools. Maybe scrounge a vintage Z80 out of an old Timex-Sinclair or something?
Ben Eater has entered the chat
The author doesn’t explain exactly what their interest in bootstrapping is, but the goal is pretty explicit:
It seems it would be a lot easier to work on the GCC compiler, and work with others to bootstrap GCC (if it hasn’t already been done). Getting the GCC Rust compiler able to compile some version of rustc probably wouldn’t be that hard, and then you can just use that version to compile up the chain to modern Rust.
That’s the
mrustcproject the author mentions. He wants Rust to be bootstrapped earlier in the process.Sure, but I guess I don’t really understand the argument. Why would Rust need to be involved earlier in the process? Isn’t the point to have a way to compile rustc completely from source?
I guess it’s cool to have multiple ways to get there, but that project would take way less work and get to the same end goal. It sounds to me like the author is trying to justify a cool project instead of trying to solve a real problem. That’s completely fine, but I think most people would be happy with the mrustc project.
I asked, and it’s to replace some of the bits that require Perl: https://hachyderm.io/@notgull/113035157972265244
You can see the full (current) sequence here: https://bootstrapping.miraheze.org/wiki/Live-bootstrap
The deeper reasoning is still not explained. C is just terrible for this. Rust is very complicated and writing a new implementation is a big project even in good languages. So using C seems tragic.
I’m going to go further and say that TinyCC isn’t bootstrapped either, since the compiler writer’s thought processes aren’t bootstrapped. You would have to use something like CompCert (i.e. all the reasoning that the programs works is embedded in the program and machine checked) and bootstrap that. It is probably doable, but not as a 1 person hobby project.
Okay. That’s just imposing a different (and at least equally arbitrary, if not moreso) definition of bootstrapping. Why does it matter that the author didn’t explain their “deeper reasoning” for having an interest in bootstrapping, or the Bootstrappable Builds project specifically? If you feel like that project isn’t meeting a sufficient bar for what counts as “bootstrapping”, or that using C as the first high-level language they bootstrap is “tragic”, take it up with that project, I guess.
I will take a look at the bootstrapping project page, but “bootstrappability” is a philosophical notion whose extent depends on what you are trying to get from it. Certainly someone who pursues it should give that some thought and reach a conclusion, rather than just following a recipe on some web site. So that’s the deeper reasoning I felt was missing.
As for C being terrible, well, why would I want to take that up with anyone? It’s simply that we know from 50 years of experience with C that writing bug-free C programs, or noticing the existence of bugs in them, is extremely difficult. If someone decides to use it for bootstrapability anyway, xkcd.com/386 would seem to apply.
collapseos.org (which uses Forth) might also be of some interest, though I think that was another questionable decision. Real transparency and boostrapability requires that the reasoning process be written out and matched up with the code. C does a pretty poor job of that compared to some alternatives.