SectorC: A C Compiler in 512 bytes • Hacker News Board

Re: SectorC: A C Compiler in 512 bytes

#71

Post by gigel82 » Thu, May 25, 2023, 5:18 PM UTC

fosslinux wrote: post #47

gigel82 wrote: post #3

I'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.

Wow, just reading through the list of steps was fascinating!

Re: SectorC: A C Compiler in 512 bytes

#72

Post by paulddraper » Thu, May 25, 2023, 5:21 PM UTC

linkdd wrote: post #48

stefncb wrote: post #40

Earlier quoted context omitted.

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.

The correct term for this is "JIT compiler."

(JIT interpreter is not a phrase I'm familiar with.)

You can also have an optimizing JIT compiler. Or further, a profiling JIT compiler.

Re: SectorC: A C Compiler in 512 bytes

#73

Post by xorvoid » Thu, May 25, 2023, 6:12 PM UTC

scrawl wrote: post #58

really interesting write-up. thanks for sharing! do you think there are any lessons that can be applied to a "normal" interpreter/compiler written in standard C? i'm always interested in learning how to reduce the size of my interpreter binaries

Hard to say. I’m fairly sure that all of modern software could easily be 2-3 orders of magnitude smaller. But, the world has decided (and I think rightfully so) that it doesn’t matter. We have massive memories and storage systems. Unless you have a very constrained system (power, etc) then I think the big bloated, lots of features approach is the winner (sadly).

Re: SectorC: A C Compiler in 512 bytes

#74

Post by xorvoid » Thu, May 25, 2023, 6:14 PM UTC

tomsmeding wrote: post #50

mihaic wrote: post #49

That 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

Yup. See “rt/lib.c” A bunch of inline machine code. The assembly mnemonics are in the comments.

Re: SectorC: A C Compiler in 512 bytes

#75

Post by scrawl » Thu, May 25, 2023, 7:22 PM UTC

xorvoid wrote: post #73

scrawl wrote: post #58

really interesting write-up. thanks for sharing! do you think there are any lessons that can be applied to a "normal" interpreter/compiler written in standard C? i'm always interested in learning how to reduce the size of my interpreter binaries

Hard to say. I’m fairly sure that all of modern software could easily be 2-3 orders of magnitude smaller. But, the world has decided (and I think rightfully so) that it doesn’t matter. We have massive memories and storage systems. Unless you have a very constrained system (power, etc) then I think the big bloated, lots of features approach is the winner (sadly).

> sure that all of modern software could easily be 2-3 orders of magnitude smaller

niklaus wirth thought similarly... in 1995![0]

i enjoy implementing array langs (k primarily) so small binaries come with the territory. really appreciated your write-up. i may try something similar for an array lang.

you might also appreciate (or detest) 'b'[1][2] - a small implementation of a "fast c compiler (called b: isomorphic to c)". it has some similarities to SectorC.

[0] https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR... [1] https://web.archive.org/web/20230117082148/https://kparc.com... [2] https://github.com/kparc/bcc (more legible)

Re: SectorC: A C Compiler in 512 bytes

#76

Post by pinum » Fri, May 26, 2023, 12:07 AM UTC

agumonkey wrote: post #44

xonix wrote: post #2

This 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

Yes! There's a public git repo here: https://repo.or.cz/tinycc.git "Public" in the sense that anyone can just push to the "mob" branch. You don't even need an account.

Such anarchy has obvious security implications but has worked remarkably well in practice. There's a mailing list too.

Re: SectorC: A C Compiler in 512 bytes

#77

Post by mikewarot » Fri, May 26, 2023, 3:56 AM UTC

I started reading the source... and digging for the part that allocates space for variables.... only to realize variable declarations are ignored and unnecessary... wow... what a breathlessly reckless hack! I love it!

It's like using an M18A1 Claymore mine and hoping it actually is aimed (and stays aimed) in the right direction.

Re: SectorC: A C Compiler in 512 bytes

#78

Post by naruhodo » Fri, May 26, 2023, 4:26 AM UTC

> I will call it the Barely C Programming Language

Or BCPL, for short.

> The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system. Derived from the typeless language BCPL, it evolved a type structure; created on a tiny machine as a tool to improve a meager programming environment, it has become one of the dominant languages of today. This paper studies its evolution. [1]

[1] https://www.bell-labs.com/usr/dmr/www/chist.html

Re: SectorC: A C Compiler in 512 bytes

#79

Post by pcvarmint » Fri, May 26, 2023, 5:28 AM UTC

kyberias wrote: post #29

userbinator wrote: post #23

I 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?

It's redundant. [0]

[0]: https://softwareengineering.stackexchange.com/questions/2460...>

Re: SectorC: A C Compiler in 512 bytes

#80

Post by agumonkey » Fri, May 26, 2023, 12:44 PM UTC

pinum wrote: post #76

agumonkey wrote: post #44

Earlier quoted context omitted.

I wonder if anybody tried to maintain TCC

Yes! There's a public git repo here: https://repo.or.cz/tinycc.git "Public" in the sense that anyone can just push to the "mob" branch. You don't even need an account. Such anarchy has obvious security implications but has worked remarkably well in practice. There's a mailing list too.

Ah well, I would never have found out. Thanks.