This is crazy cool! Esolangs have been a hobby of mine, (more just an interest lately, since I haven't built any in a while,) so this is like a fun code golf game for compilation. Nice work, and even better, nice explanation article!
Writing a C compiler in 500 lines of Python
81–90 of 183 posts
Re: Writing a C compiler in 500 lines of Python
#82Writing your own compiler - demystifies compilers, interpreters, linkers/loaders and related systems software, which you now understand. This understanding will no doubt one day help in your debugging efforts; - elevates you to become a higher level developer: you are now a tool smith who can make their own language if needed (e.g. to create domain specific languages embedded in larger systems you architect). So cong…
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation.
It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer.
And somehow I have ended up with a very strong bias against DSLs.
Re: Writing a C compiler in 500 lines of Python
#83Earlier quoted context omitted.
But they could've fixed that by going a=(*p) and a=(-b); Kind of how we use (*p)->next instead of *p->next where p is node_t**
That seems a little backwards and barbaric, though right? Imagine if we had to watch out for this as a common pitfall: // BUG! Actually subtracts x from current val of neg_x. neg_x = -x; Even moreso, how would these two lines behave? Would they differ in semantics? n = -5 n =- 5 Overall, -= is just so much less ambiguous. EDIT: To your point about ->, I personally think C would be better if: *p->next parsed as: (*p)-…
As you note in your edit; we already have to watch for that pitfall :)
so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next;
Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).
Re: Writing a C compiler in 500 lines of Python
#84Cool. Now try writing a Python compiler in 500 lines of C.
Re: Writing a C compiler in 500 lines of Python
#85Earlier quoted context omitted.
I think Borland’s Turbo Pascal was also a single pass compiler that emitted machine code as COM files.
Surely it is a feature of all Pascal compilers that they are single pass. I thought that it was part of the specification of the language that it be possible to compile in a single pass.
There's a bunch of LLVM-based Pascal compilers these days. I doubt they are single pass, given how LLVM works. (And in general, any optimizing compiler is most likely doing multiple passes.)
You are right about Pascal's original design. Though I'm not sure if that's still true about modern versions of the language?
Re: Writing a C compiler in 500 lines of Python
#86> Instead, we'll be single-pass: code generation happens during parsing IIRC, C was specifically designed to allow single-pass compilation, right? I.e. in many languages you don't know what needs to be output without parsing the full AST, but in C, syntax directly implies semantics. I think I remember hearing this was because early computers couldn't necessarily fit the AST for an entire code file in memory at once
I'm not sure, haven't looked at the codebases of old compilers in a long time. Definitely a lot of the language is pretty amenable to it, especially if you have unstructured jumps for e.g. the for advancement statement. I had a distinct feeling while writing the compiler every time I added a new feature that "wow, the semantics work exactly how I'd like them to for ease of implementation." Compare that to, say, Rust,…
What you are saying is true for a naive C compiler.
Once you want to optimize or analyse, things become more complicated.
> Compare that to, say, Rust, which would be pretty painful to single-pass compile with all the non-local behavior around traits.
Type inference also spans a whole function, so you can't do it in a single pass through the code. (But it's still tamer than in eg Haskell, where type inference considers your whole program.)
Re: Writing a C compiler in 500 lines of Python
#87Writing your own compiler - demystifies compilers, interpreters, linkers/loaders and related systems software, which you now understand. This understanding will no doubt one day help in your debugging efforts; - elevates you to become a higher level developer: you are now a tool smith who can make their own language if needed (e.g. to create domain specific languages embedded in larger systems you architect). So cong…
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation. It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer. And somehow I have ended up with a very strong bias against DSLs.
> And somehow I have ended up with a very strong bias against DSLs.
Most DSLs are bad, partially because most people are bad at designing languages.
Embedded DSLs can be quite neat. Eg Haskell makes it easy to embed something like DSLs inside your Haskell code.
(If you squint a bit, the ability to define your own functions in any language goes in that direction of allowing you to define your own mini-sub-language that handles your problem better. Haskell (and the Lisps) just dial that kind of approach up to 11.)
Re: Writing a C compiler in 500 lines of Python
#88Writing your own compiler - demystifies compilers, interpreters, linkers/loaders and related systems software, which you now understand. This understanding will no doubt one day help in your debugging efforts; - elevates you to become a higher level developer: you are now a tool smith who can make their own language if needed (e.g. to create domain specific languages embedded in larger systems you architect). So cong…
Took me seven years to do my own dynamic one that ended up being very similar to python2 with curly braces. Every programmer should try it
Writing your own interpreter can be a lot of fun.
Not sure if most people will get much extra out of writing their own compiler, too?
Re: Writing a C compiler in 500 lines of Python
#89Earlier quoted context omitted.
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation. It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer. And somehow I have ended up with a very strong bias against DSLs.
> And somehow I have ended up with a very strong bias against DSLs. Most DSLs are bad, partially because most people are bad at designing languages. Embedded DSLs can be quite neat. Eg Haskell makes it easy to embed something like DSLs inside your Haskell code. (If you squint a bit, the ability to define your own functions in any language goes in that direction of allowing you to define your own mini-sub-language tha…
I don't necessarily think the DSLs are badly designed. But personally I find the overhead in learning and remembering a new language to be enormous. I instantly drop from extremely high productivity in my language of choice to fumbling around like a newbie. And often DSLs are used for smallish tasks that you work on, write the code, then leave for a long time. Then you come back to it and have no idea how that language worked, its pecularities, etc.
It had better have an extremely high payoff to justify that cost.
Re: Writing a C compiler in 500 lines of Python
#90[flagged]