This 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!
SectorC: A C Compiler in 512 bytes
21–30 of 82 posts
Re: SectorC: A C Compiler in 512 bytes
#22I'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.
I can't help but wonder if this is written in x86-16 bit mode to implicitly use Real Mode BIOS functions and platform interfaces as well.
There's something to be said for taking advantage of that existing code; but if that's a dependency it should be part of the environment manifest. Everything has (most things have) a context where it might be useful and that should be included in the explanation so a tool isn't misused and so incorrect expectations aren't set.
Re: SectorC: A C Compiler in 512 bytes
#23I saw the repeating 'A' at the end of the base64 text and thought "it's not even 512 bytes; it's smaller!"
That said, the title is just a little clickbaity --- it's a C-subset compiler, and more accurately a JIT interpreter. There also appears to be no attempt at operator precedence. Nonetheless, it's still an impressive technical achievement and shows the value of questioning common assumptions.
Finally, I feel tempted to offer a small size optimisation:
sub ax,2
dec ax
dec ax
You may be able to use single-byte xchg's with ax instead of movs, and the other thing which helps code density a lot in 16-bit code is to take advantage of the addressing modes and LEA to do 3-operand add immediates where possible.
Re: SectorC: A C Compiler in 512 bytes
#24Great read and awesome achievement. Could see this being useful for smaller microcontrollers.
Re: SectorC: A C Compiler in 512 bytes
#25Now they just need to port something like oneKpaq to 16 bit or maybe something from the extremely tiny decompressor thread [1], just to test compression level to get an idea kpaq on its quickest setting(taking minutes instead of what could be days on its highest) reduced SectorC to 82.81% of its size, of course adding the 128 bit stub knocked it to 677 bytes. It would be interesting to try it on the slowest takes day to bruteforce setting, but I'm not going to attempt that.
Some of the compressors in that forum thread since they are 32 bytes and such, might find it easier to get net gains.
[0] https://github.com/temisu/oneKpaq
[1] https://encode.su/threads/3387-(Extremely)-tiny-decompressor...
Re: SectorC: A C Compiler in 512 bytes
#26Now they just need to port something like oneKpaq to 16 bit or maybe something from the extremely tiny decompressor thread [1], just to test compression level to get an idea kpaq on its quickest setting(taking minutes instead of what could be days on its highest) reduced SectorC to 82.81% of its size, of course adding the 128 bit stub knocked it to 677 bytes. It would be interesting to try it on the slowest takes day…
LZ decompressors are tiny, as your second link discusses, but it is unlikely that they'll find much redundancy that could easily be removed from the uncompressed program itself, thus removing the need to use them.
Re: SectorC: A C Compiler in 512 bytes
#27wow, this is impressive.
I wrote a similar x86-16 assembler in https://github.com/kvakil/0asm/>. I did find a lot of similar tricks were helpful: using gadgets and hashes. Once trick I don't see in sectorc which shaved quite a bit off of 0asm was self-modifying code, which 0asm uses to "change" to the second-pass of the assembler. (I wrote some other techniques here: https://kvakil.me/posts/asmkoan.html>.)
bootOS (https://github.com/nanochess/bootOS>) and other tools by the author are also amazing works of assembly golf.
Re: SectorC: A C Compiler in 512 bytes
#28If you don't use this... are you even suckless?
Re: SectorC: A C Compiler in 512 bytes
#29I saw the repeating 'A' at the end of the base64 text and thought "it's not even 512 bytes; it's smaller!" That said, the title is just a little clickbaity --- it's a C-subset compiler, and more accurately a JIT interpreter. There also appears to be no attempt at operator precedence. Nonetheless, it's still an impressive technical achievement and shows the value of questioning common assumptions. Finally, I feel temp…
What does Just In Time mean for an interpreter?
Re: SectorC: A C Compiler in 512 bytes
#30This 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.
Did you read about the guix full source bootstrap the other day? They've shrunk the bootstrap seed down to a 357-byte program: https://guix.gnu.org/blog/2023/the-full-source-bootstrap-bui...
Is Nix incorporating this work as well? I fully support and want Guix to survive, but it seems well behind in mind share, and I would love if Nix could become similarly repeatable and reproducible.