Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a C compiler in 500 lines of Python (2023)

vgel.me

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Writing a C compiler in 500 lines of Python (2023)

#61

Post by Joker_vD »

dlcarrier wrote: post #48
Buttons840 wrote: post #40

After many years of programming in other languages, I finally learned C, and came to realize that there aren't actually any compilers that implement all of the C spec. Even GCC and Clang have their grey areas and their bugs. Before this, I had thought that C was a simple language. An idea propped up by articles likes this, as well as the oft touted fact that nearly every embedded system has a C compiler; no matter wh…

C has a lot of feature creep, and C++ is just C with extra feature creep. The original C compiler ran on a PDP-11, which usually had just kilobytes of RAM. The syntax was written around compiling with such limited resources, hence the need for headers, primitives, semicolons, linkers, and so on. It has changed a lot over time, but seems to be adding baggage, not removing it.

The original C compiler had no need for headers or function prototypes/forward declarations. Of course, it also was not a single-pass compiler: it had two (and a half) passes and generated assembly that would then be assembled by a two-pass assembler.

Re: Writing a C compiler in 500 lines of Python (2023)

#62

Post by Joker_vD »

comonoid wrote: post #51
MarsIronPI wrote: post #17

I find it surprising that a single-pass compiler is easier to implement than a traditional lexer->parser->AST->emitter. (I'm not a compiler expert, though.) I'd have expected that generating an AST would be at least as simple, if not simpler. Plus by generating an AST, doing some simple optimization is a lot easier: one can pattern-match parts of the AST and replace them with more efficient equivalents. Maybe I'm ove…

C was designed to be compiled with a single-pass compiler.

It wasn't; the original C compiler had two passes, and built expression trees in the first pass which the second pass would turn into assembly (and the original as on UNIX also had two passes).

Re: Writing a C compiler in 500 lines of Python (2023)

#63

Post by whobre »

comonoid wrote: post #51
MarsIronPI wrote: post #17

I find it surprising that a single-pass compiler is easier to implement than a traditional lexer->parser->AST->emitter. (I'm not a compiler expert, though.) I'd have expected that generating an AST would be at least as simple, if not simpler. Plus by generating an AST, doing some simple optimization is a lot easier: one can pattern-match parts of the AST and replace them with more efficient equivalents. Maybe I'm ove…

C was designed to be compiled with a single-pass compiler.

C was not designed at all. It evolved from B, by adding types to it.

Re: Writing a C compiler in 500 lines of Python (2023)

#64

Post by adamors »

pjmlp wrote: post #60
adamors wrote: post #53

Earlier quoted context omitted.

Exactly, I was looking into refreshing my C knowledge recently and K&R is still heavily recommended.

Go with such a book instead, https://www.manning.com/books/modern-c

How does this compare to https://nostarch.com/effective-c-2nd-edition ?

Re: Writing a C compiler in 500 lines of Python (2023)

#65

Post by pjmlp »

adamors wrote: post #64
pjmlp wrote: post #60

Earlier quoted context omitted.

Go with such a book instead, https://www.manning.com/books/modern-c

How does this compare to https://nostarch.com/effective-c-2nd-edition ?

I guess it is also a good one, both authors are still active on WG14, if I am not mistaken.

Re: Writing a C compiler in 500 lines of Python (2023)

#66

Post by fuzztester »

Joker_vD wrote: post #61
dlcarrier wrote: post #48

Earlier quoted context omitted.

C has a lot of feature creep, and C++ is just C with extra feature creep. The original C compiler ran on a PDP-11, which usually had just kilobytes of RAM. The syntax was written around compiling with such limited resources, hence the need for headers, primitives, semicolons, linkers, and so on. It has changed a lot over time, but seems to be adding baggage, not removing it.

The original C compiler had no need for headers or function prototypes/forward declarations. Of course, it also was not a single-pass compiler: it had two (and a half) passes and generated assembly that would then be assembled by a two-pass assembler.

Yes, function prototypes were introduced in the first ANSI version of C, IIRC, which came some years after the original C. The prototype feature was described in the second version of the classic K&R C book, The C Programming Language.

Re: Writing a C compiler in 500 lines of Python (2023)

#67

Post by fuzztester »

dlcarrier wrote: post #49
marssaxman wrote: post #28

Earlier quoted context omitted.

A single-pass compiler is easier to implement in part because you're not going to do any of that optimization. You're writing a single-pass compiler either because you're banging out a quick sketch of an idea, and you don't care about production use, or because you've time-traveled back to the '70s or the '80s, where processors were so painfully slow and memory so eye-wateringly expensive that you might not even be a…

I used to write software on my HP calculator, when I was bored in classes, before smartphones existed. It used a tokenized language called RPL, and the editor would read and parse just enough tokens to fill up the screen. I miss how fast it was, compared to modern computers. VS Code is much laggier in comparison.

Which model of HP calculator?

And what kinds of programs could you write with it?

Re: Writing a C compiler in 500 lines of Python (2023)

#68

Post by fuzztester »

whobre wrote: post #63
comonoid wrote: post #51

Earlier quoted context omitted.

C was designed to be compiled with a single-pass compiler.

C was not designed at all. It evolved from B, by adding types to it.

Yes.

And B evolved from BCPL:

https://en.m.wikipedia.org/wiki/BCPL

I had read the book about BCPL by Martin Richards, creator of the language. it was quite interesting. IIRC, after describing the language, he gave some examples of small system software routines or utilities, written in it.

https://en.m.wikipedia.org/wiki/Martin_Richards_(computer_sc...

Re: Writing a C compiler in 500 lines of Python (2023)

#69

Post by aw1621107 »

1718627440 wrote: post #52
Buttons840 wrote: post #40

After many years of programming in other languages, I finally learned C, and came to realize that there aren't actually any compilers that implement all of the C spec. Even GCC and Clang have their grey areas and their bugs. Before this, I had thought that C was a simple language. An idea propped up by articles likes this, as well as the oft touted fact that nearly every embedded system has a C compiler; no matter wh…

> [0]: https://faultlore.com/blah/c-isnt-a-language/#you-cant-actua... This blog post is full of misconceptions. It starts by asserting, that C defines an ABI and then complains that everything is so complicated, because actually C doesn't define it. C is defined in terms of behaviour of the abstract C machine. As far as C is concerned, there is no ABI. C only prescribes meaning to the language, it does not prescribe…

> I don't know why the choice to use the compiler to implement parsing a C header is framed as a bad thing.

Not sure I agree with this interpretation, though maybe I'm focusing on a different part of the article than you are. Where you are getting the negative sense from?

That being said, I don't think it's too hard to imagine why someone might be a bit hesitant to use a C/C++ compiler to parse C/C++ headers - for example, it can be a pretty big dependency to take on, may add friction for devs/users, and integration with your own tool may be awkward and/or an ongoing time sink especially if you're crossing an FFI boundary or if the API you're using isn't stable (as I believe it is the case for LLVM).

> There is a reason it is called intMAX_t! It does not HAVE a definite size, it is the MAXimal size of an integer on that platform.

I think this somewhat misses the point of the bit you quoted. In context, it's basically saying that grabbing "real" C type info for interop is so painful that people will hard-code "reasonable" assumptions instead.

> When you want your program to have a stable ABI, that doesn't change when your platform supports larger integer types, you just don't use intMAX_t!

My impression is that the problem is less intmax_t changing and more that intmax_t can change out of sync. Even if you assume every use of intmax_t in a public API corresponds to an intentional desire for the bit width to evolve over time, you can still run into nasty issues if you can't recompile everything at once (which is a pretty strong constraint on the C/C++ committees if history is any indication).

Re: Writing a C compiler in 500 lines of Python (2023)

#70

Post by pjmlp »

fuzztester wrote: post #66
Joker_vD wrote: post #61

Earlier quoted context omitted.

The original C compiler had no need for headers or function prototypes/forward declarations. Of course, it also was not a single-pass compiler: it had two (and a half) passes and generated assembly that would then be assembled by a two-pass assembler.

Yes, function prototypes were introduced in the first ANSI version of C, IIRC, which came some years after the original C. The prototype feature was described in the second version of the classic K&R C book, The C Programming Language.

Function prototypes came to ANSI/ISO C via the ongoing work on ISO C++.
Post reply on HN