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

vgel.me

Post reply on HN
Print view View original

131–140 of 183 posts

Re: Writing a C compiler in 500 lines of Python

#131

Post by foldr »

ak_111 wrote: post #129
foldr wrote: post #128

Earlier quoted context omitted.

>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language? You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).

Would it be possible to create two versions of the language: microC for embedded C programs where these decisions matter, and standard C for PC/servers which basically all use the same representation for these scalers? My main point is that a C programmer today is forced to learn dozens of rules just to cater for many niche platforms that they will probably never target, so if you were to separate those two use cases…

Yes, for sure. I don't disagree with your overall point. Just pointing out that people are still writing C code for 8 and 16 bit platforms today.

Re: Writing a C compiler in 500 lines of Python

#132

Post by 59nadir »

hot_gril wrote: post #95
stevage wrote: post #82

Earlier 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.

Yeah, nowadays a DSL is almost never a good idea. A library for some pre-existing flexible language can do the job without reinventing a whole lot of wheels. The most specific languages I can think of that make sense are SQL and Solidity. But DSLs are tempting, especially among the more passionate programmers, so at work we've ended up with a lot of them. All of them are tripping hazards.

As far as languages go SQL is pretty bad, though. It's not even really a good representation of what it's trying to do. I think if SQL is a good domain specific language the bar seems very low.

Re: Writing a C compiler in 500 lines of Python

#133

Post by MrYellowP »

I am really confused by what people call compilers nowadays. This is now a compiler that takes input text and generates output text, which then gets read by a compiler that takes input text and generates JIT code for execution.

This is more of a transpiler, than an actual compiler.

Am I missing something?

Re: Writing a C compiler in 500 lines of Python

#134

Post by 59nadir »

laurencerowe wrote: post #70
marcodiego wrote: post #7

It is interesting to think that 500 lines of code is something one can write in one or two days. But, writing a C compiler in 500 of comprehensible code (even in python) is challenge in itself that may take months after a few years of solid learning. I wonder if is this a good path to becoming an extremely productive developer. If some one spends time developing projects like this, but for different areas... A kernel…

As an experienced developer who did not do a compilers course at university I was able to write a SQL/JSONPath evaluator in TypeScript in a week or so. I don’t expect a minimal C compiler would be that much more complex. Essentially all you need is a grammar, parser library and a couple of tree walkers to convert the AST first to expand macros and then convert to assembly. A production compiler with all its optimisat…

You don't need a parser library; writing the tokenizer + parsing logic isn't a very time consuming endeavor and the code doesn't suffer from it either. The upside is also that you're not taking on some monstrosity of a library for something you can implement in a tenth of the lines yourself. You'll also end up with something you actually fully understand yourself as well, which should be a big plus.

Re: Writing a C compiler in 500 lines of Python

#135

Post by foldr »

mananaysiempre wrote: post #130
foldr wrote: post #128

Earlier quoted context omitted.

>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language? You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).

In fact, the default integer promotions together with the requirement that unsigned int hold numbers until at least 2^16 is the main reason C code for 8-bitters is somewhat... stylized, to put it mildly.

I think that's actually an interesting example of how C sees itself as a high level language (from the perspective of the early 70s), even though we now categorize it as low-level. You'd expect the default integer type in a high level language to be able to store values that are large enough for an interesting range of practical tasks; 16 bits is arguably the bare minimum to meet that requirement.

Re: Writing a C compiler in 500 lines of Python

#136

Post by traes »

MrYellowP wrote: post #133

I am really confused by what people call compilers nowadays. This is now a compiler that takes input text and generates output text, which then gets read by a compiler that takes input text and generates JIT code for execution. This is more of a transpiler, than an actual compiler. Am I missing something?

To quote the great Bob Nystrom's Crafting Interpreters, "Compiling is an implementation technique that involves translating a source language to some other — usually lower-level — form. When you generate bytecode or machine code, you are compiling. When you transpile to another high-level language, you are compiling too."

Nowadays, people generally understand a compiler to be a program that reads, parses, and translates programs from one language to another. The fundamental structure of a machine code compiler and a WebAssembly compiler is virtually identical -- would this project somehow be more of a "real" compiler if instead of generating text it generated binary that encoded the exact same information? Would it become a "real" compiler if someone built a machine that runs on WebAssembly instead of running it virtually?

The popular opinion is that splitting hairs about this is useless, and the definition of a compiler has thus relaxed to include "transpilers" as well as machine code targeting compilers (at least in my dev circles).

Re: Writing a C compiler in 500 lines of Python

#137

Post by circuit10 »

foldr wrote: post #128
ak_111 wrote: post #124

Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…

>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language? You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).

If you’re writing code for those why not just use the smaller data types if you don’t need bigger ones? That way it will work efficiently on both and the behaviour will be consistent

Re: Writing a C compiler in 500 lines of Python

#138

Post by mananaysiempre »

> [Building parse trees] is really great, good engineering, best practices, recommended by experts, etc. But... it takes too much code, so we can't do it.

It takes too much code in Python. (Not a phrase one gets to say often, but it’s generally true for tree processing code.) In, say, SML this sort of thing is wonderfully concise.

Re: Writing a C compiler in 500 lines of Python

#140

Post by fodkodrasz »

bsder wrote: post #93
speps wrote: post #10

Earlier quoted context omitted.

Linked from another thread: http://cm.bell-labs.co/who/dmr/chist.html It explains the memory limits and what happened :) > After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its s…

Infix parsing chews up a remarkable amount code and memory. It's scary just how much easier it is to parse languages without infix parsing.

where it takes up the memory in the human brain, where we have more limited working set, than in computers. That is probably why postfix notation is mostly a thing of the past by now in languages intended to be used by humans.
Post reply on HN