This project sounds kind of masochistic but the idea is to bootstrap Rust from tinycc, and have traceability down to the lowest level assembly code. There is a step missing though? Tinycc is written in C after all.
I think it would make more sense to bootstrap from a small Lisp written in assembly language, if the traceability goal is worthwhile at all. There is nothing special about C.
The main thing is that TinyCC has already been bootstrapped.
Check out this page on bootstrappable.org. Basically they start with a 200 something byte binary (hex0) that can act as an assembler, then using a bunch of layers of tools and compilers you can bootstrap a whole system. I think they use stage0 to build M2-Planet, use that to build GNU Mes, and use that to build TinyCC.
So a project like this fits neatly into that bootstrapping path. It could be done other ways, but starting from a fairly complete C compiler makes it a lot easier than building an entire path from scratch.
I wish that were true, but isn't it somewhat wishful thinking? Even an assembly-language Lisp would require an operating system in order to build a functioning compiler, wouldn't it? And operating system APIs are in C.
Edit: more importantly, as the post explains, the special thing about C is the existence of TinyCC.
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?
Operating system interfaces use the C ABI, but they don't require you to use C.
Actually that's true on most OSes, but not Linux - that uses syscalls as its interface not function calls to a shared library, so it's the syscall ABI.
I still feel like designing and bootstrapping your own higher level language is going to be less painful overall than writing a Rust compiler in C. And probably more fun.
A lot of this bootstrapping stuff comes back to the 'trusting trust' attack. You could write a compiler that adds some malicious code to programs it compiles. But the thing is, it could also insert it's own malicious code when compiling a compiler. So you look at your code, and the code of your compiler, and everything looks fine, but the exploit is still there. Someone wrote an example in rust.
Theoretically there could also be bugs that propagate this way. So to fully trust your code is doing what you think it is, you'd need a chain of compilers back to hand coded assembly.
Why would a Rust compiler written in C be more trustworthy than one written in Rust?
If the idea is that, in an ideal world, we would compile each layer of compilers from assembly-up-to-Rust for each build, that seems even more risky as then you have to trust each compiler instead of just one.
Didn't Rust itself used to have a compiler written in a different language? I mean, obviously it would've had to at some point but I think I remember reading about them abandoning it once they didn't need it. Why not use that?
You can technically do it, but it's a convoluted path. The article talks about it. Basically to bootstrap that way you need to go through a lot of versions of rust, compile rust 0.7 in ocaml, compile ocaml in scheme, and compile scheme in C using gcc. For gcc you need to compile a chain of versions back to when it was written in C instead of C++, plus the whole TinyCC bootstrapping path.
Ah okay. The article was a little over my head so I mostly skimmed it. This makes sense what you're saying though. It's easy to forget the level of bootstrapping they're trying to do is all the way to assembly.
It's the sort of thing if you think about too long you'll get paranoid and start using Gentoo exclusively lol.