SectorC: A C Compiler in 512 bytes

Post by DesiLurker » Fri, May 26, 2023, 3:54 PM UTC

geocar wrote: post #67

vitiral wrote: post #10

Earlier quoted context omitted.

In my experience, probably at least a 200-400 lines of C (another 512 bytes minimum? I don't know the conversion). The problem is not just declaring structs but accessing them, referencing them, accessing/referencing fields and subfields, etc. That has to all be in the syntax. For such a minimal project you can ignore initialization. I did all this while adding maybe 500 lines of C to GitHub.com/vitiral/fngi. Never t…

Once upon a time, when += was spelled =+, struct members in C were global names whose "values" were the offsets from the beginning of the struct[1]; a.b is simply a[ptrtab[b]] and a->b is a[0][ptrtab[b]]. [1]: This is why all of the names of struct members in unix are "needlessly" prefixed; i.e. struct stat.st_mode is not struct stat.mode because that could conflict with struct foo.mode until the early 1980s.

Ah that explains it, I wondered about those old struct defs.

Post by geocar » Sat, May 27, 2023, 6:02 AM 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).

It depends on what you mean by "winning".

You can't have the goal for the code to generate revenue, at equal priority for it to be easy for lots of inexperienced programmers to work on (i.e. maximise costs), because the only time you're going to choose "readability" and "unit tests" (and other things with direct costs) is because of doubts you have in your ability to do the former without this hedging of your bets a little. If you disagree, you do not know what I said.

And so they ask: What is the next great software unicorn? Who knows, but being able to rapidly put stuff in front of consumers and ask is this it? has proven to be an effective way at finding out. And if you go into a product not knowing how (exactly) to generate revenue, you can't very well design a system to do it.

Do you see that? Software is small when it does what it is supposed to by design; Software is big when it does so through emergence. Programmers can design software; non-programmers cannot. And there are a lot more non-programmers. And in aggregate, they can outcompete programmers "simply" by hiring. This is why they "win" in your mind.

But this is also true: programmers who know what exactly makes money can make as much money as they want. And so, if someone has a piece of tiny software that makes them a ton of money, they're not going to publish it; nobody would ever know. 2-3 orders of magnitude could be taking a software product built by 100 people and doing it with 1-2. The software must be smaller, and that software I think "wins" because that's two people sharing that revenue instead of 100+management.

To that end, I think learning how to make tiny C compilers is good practice for seeing 2-3 orders of magnitude improvement in software design elsewhere, and you've got to get good at that if you want the kind of "wins" I am talking about.

Re: SectorC: A C Compiler in 512 bytes

Re: SectorC: A C Compiler in 512 bytes