Great writeup!
Especially liked this nugget:
> (NOTE: This grammar is 704 bytes in ascii, 38% larger than it's implementation!)
SectorC: A C Compiler in 512 bytes
41–50 of 82 posts
Re: SectorC: A C Compiler in 512 bytes
#42This is fascinating, I really did not think it was possible to implement even a tiny subset of C in just 512 bytes of x86 code. Using atoi() as a generic hash function is a brilliantly awful hack!
Yeah, this was great:
Hashes are perhaps the holy-grail of computer-science. With a good hash, we can just side-step all the hard problems by trading them for an even harder problem (hash collisions), and then we just ignore that harder problem. Brilliant. (sticks fingers in ears)
Re: SectorC: A C Compiler in 512 bytes
#43something like this could be interesting for deep-space applications where you only have a bare metal environment with hardened processor and limited memory & of course ping time of days (to earth). or alternatively for embedding a C compiler inside a LLM to use the LLM as a form of virtual machine.
You mean like for retrofitting an existing satellite? It seems like we're beyond the era of extremely constrained embedded environments, even for space hardware. Several hundred Mhz PowerPC based avionics computers with hundreds of MB of RAM seemed pretty common 15 years ago.
What would a C interpreter do that wouldn't be done better by simply uploading a new compiled binary, though? The source code is most likely less space efficient than machine code.
Re: SectorC: A C Compiler in 512 bytes
#44This reminded me the idea of compilers bootstrapping ( https://news.ycombinator.com/item?id=35714194 ). That is, now you can code in SectorC some slightly more advanced version of C capable of compiling TCC ( https://bellard.org/tcc/ ), and then with TCC you can go forward to GCC and so on.
I wonder if anybody tried to maintain TCC
Re: SectorC: A C Compiler in 512 bytes
#45This reminded me the idea of compilers bootstrapping ( https://news.ycombinator.com/item?id=35714194 ). That is, now you can code in SectorC some slightly more advanced version of C capable of compiling TCC ( https://bellard.org/tcc/ ), and then with TCC you can go forward to GCC and so on.
The TCC step seems unnecessary. If you've got a SectorC C compiler sufficient to compile TCC, it can probably compile the bootstrap compiler used in GCC's 3 stage build process. The bigger issue is probably getting the ancillary tools up and running (a shell, make, coreutils, ...) https://gcc.gnu.org/install/build.html
The method described in the page you reference, does not exclude the possibility that the compiler you start with, contains malicious code, and recognizes that it is compiling the GCC code base. It is not true bootstrapping as described in [0]. If you read through [1] you will see that even getting a fairly recent version of TCC to compile is not that simple.
[0] https://bootstrappable.org/ [1] https://bootstrapping.miraheze.org/wiki/Live-bootstrap
Re: SectorC: A C Compiler in 512 bytes
#46Amazing.
Re: SectorC: A C Compiler in 512 bytes
#47I'm wondering if you can build an actual "Linux from scratch" with this as the lowest level, without the need to use a host system at all.
Not using this, but tangentially related is (full disclosure, i am a maintainer of this project) live-bootstrap, which uses about a KB of binary to do a full "Linux from scratch" style thing - read https://github.com/fosslinux/live-bootstrap/blob/master/part... for all 143 steps you have to go through to get there.
Re: SectorC: A C Compiler in 512 bytes
#48Earlier quoted context omitted.
Compiling to machine instructions and then executing the compiled output, instead of executing the AST directly.
That's a just-in-time compiler.
An interpreter with a JIT compiler is able to do more optimizations because it has the runtime context to make decisions, while a AOT (ahead of time) compiler will not know anything about what happens at runtime.
This is why some JIT'd languages (like Javascript) can be sometimes faster than C.
Re: SectorC: A C Compiler in 512 bytes
#49That is insane, congrats.
I would have wished some explanation on where the function calls like vga_init and vga_set_pixel come from, I'm not a graybeard yet.
Re: SectorC: A C Compiler in 512 bytes
#50That is insane, congrats. I would have wished some explanation on where the function calls like vga_init and vga_set_pixel come from, I'm not a graybeard yet.
They're from the runtime, which is just concatenated with the program to be run: https://github.com/xorvoid/sectorc/blob/main/rt/lib.c