Live data from Hacker News

TinyCompiler: A compiler in a week-end

ssloy.github.io

111–120 of 120 posts

Re: TinyCompiler: A compiler in a week-end

#111
post #79
post #2

I appreciate how wonderfully simple and dependency free this is. More often than not people just want to write a compiler of sorts without bison or yacc, or LLVM, and just convert expressions into assembler or vm-like instructions that _just run_. This is a great starting point for that, and I wish I had something like it 10 years ago. (Crenshaw's Let's Build a Compiler is an excellent source too if you want to go on…

I’d argue that you should start with doing an interpreter and push it as long as you can. But once you’re ready to generate code, use llvm or something like that because you are going to hit very problematic roadblocks early in your effort that will kill your interest in compilers otherwise. Some examples are: ensuring you can compare expressions for equality, ensuring that changed expressions don’t violate dominance…

That's right. Crenshaw's LBAC can make you an interpreter too. LBAC's magic lies in single token read ahead, single character identifiers, and single character digits. It parses its BNF grammar only with recursive function calls (no stacks, no tables for operator precedence, etc). The final language you build is almost useless, but it is done without a standard library (eg. resizable strings, resizable arrays, stacks, queues, associative containers), and serves as an introduction to get one hooked on more advanced compiler theory like SSA. I love OP's work. I consider OP's implementation (and similarities) to be a modern day LBAC. It's just that LBAC is one of those things I'd take to the grave. I have never found such a concise introductory text that produces a working final example in such delightful piecewise prose.

Re: TinyCompiler: A compiler in a week-end

#112
post #110

Earlier quoted context omitted.

We agree on a lot of things, but QBE is off the table. Complexity and kloc are loosely correlated. Cranelift and libfirm are of equivalent size while Cranelift is in Rust and has wonderful compiler engineers working on it. https://c9x.me/git/qbe.git/tree/rega.c QBE is a one person performance art project.

This code looks a lot like the Unix V6 kernel code or the source code to Steve Johnson's pcc C compiler. It's indeed too sparsely commented, but it's not as bad as you made it sound.

... and it is getting 70% of gcc speed...

Re: TinyCompiler: A compiler in a week-end

#113
post #2

I appreciate how wonderfully simple and dependency free this is. More often than not people just want to write a compiler of sorts without bison or yacc, or LLVM, and just convert expressions into assembler or vm-like instructions that _just run_. This is a great starting point for that, and I wish I had something like it 10 years ago. (Crenshaw's Let's Build a Compiler is an excellent source too if you want to go on…

Not to take away from the author or you, but we had things like this 10 years ago https://github.com/ymyzk/tinyc/tree/master/tinyc

Unless I am mistaken, this uses LLVM?

Re: TinyCompiler: A compiler in a week-end

#116

Earlier quoted context omitted.

Not to take away from the author or you, but we had things like this 10 years ago https://github.com/ymyzk/tinyc/tree/master/tinyc

Unless I am mistaken, this uses LLVM?

I'm the author of ymyzk/tinyc and was surprised to see my project mentioned here after more than 10 years. Since the README is written in Japanese, let me answer in English here. The project has two backends: one for NASM (x86) and another for LLVM IR.

Re: TinyCompiler: A compiler in a week-end

#117

Earlier quoted context omitted.

Not to take away from the author or you, but we had things like this 10 years ago https://github.com/ymyzk/tinyc/tree/master/tinyc

Unless I am mistaken, this uses LLVM?

It can. It can also output x86 nasm, here's the relevant part.

https://github.com/ymyzk/tinyc/blob/master/tinyc/generator/n...

Re: TinyCompiler: A compiler in a week-end

#118
post #79
post #2

I appreciate how wonderfully simple and dependency free this is. More often than not people just want to write a compiler of sorts without bison or yacc, or LLVM, and just convert expressions into assembler or vm-like instructions that _just run_. This is a great starting point for that, and I wish I had something like it 10 years ago. (Crenshaw's Let's Build a Compiler is an excellent source too if you want to go on…

I’d argue that you should start with doing an interpreter and push it as long as you can. But once you’re ready to generate code, use llvm or something like that because you are going to hit very problematic roadblocks early in your effort that will kill your interest in compilers otherwise. Some examples are: ensuring you can compare expressions for equality, ensuring that changed expressions don’t violate dominance…

That's great advance in the general, modern case.. however, I want to write small compilers for an archaic minicomputer where no llvm or similar exists or can exist, and for that purpose articles like this are inspirational and very useful.

Re: TinyCompiler: A compiler in a week-end

#119

Earlier quoted context omitted.

I have the greatest respect for Prof. Kernighan, but history hasn't been kind to C's unbounded arrays and strings, however convenient they may be for the programmer. Moreover, just two years after his critique, Turbo Pascal would come out with an environment that is still revered as a pioneering and exceptionally productive IDE. It outsold C compilers by multiple orders of magnitude in the mid-1980s. (And that's igno…

Turbo Pascal wasn't just a good tool, it was a pioneer in how it was marketed and priced. It was relatively affordable, only $49, at a time when tools generally cost in the hundreds. And they ran monthly ads in nearly every computer magazine. If you wanted to hack on things on your PC, and you didn't already work for a company that would buy you to tools, you really had two choices, BASIC and Turbo Pascal.

Turbo Pascal was fantastic when it arrived. A revolution. And not just the affordable price, there was also the "book license". The compiler could be used by any number of people, anywhere, just not at the same time. And suddenly there was speed, very quick development cycle, easy debugging, and, not the least, LOTS of memory unlike other compiler environments I used at the time. The editor and compilers typically used so much memory that there was barely enough room to write your code. Not so with Turbo Pascal.

Re: TinyCompiler: A compiler in a week-end

#120
post #80

I've been a big fan of the author's tiny renderer. Nice to see a tiny compiler too!

That sounds interesting! He seems to have four tiny renderers pinned on his GitHub page; is https://github.com/ssloy/tinyrenderer the one you're recommending? What do you like about it?

Maybe they recommend that only given this is the one linked on the webpage of this post: https://ssloy.github.io/tinyrenderer/
Post reply on HN