Live data from Hacker News

TinyCompiler: A compiler in a week-end

ssloy.github.io

91–100 of 120 posts

Re: TinyCompiler: A compiler in a week-end

#91
post #90
post #60

Earlier quoted context omitted.

Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.

You mean Circle can output correct intermediate code for the latest gcc code? Or valve mesa aco code?

That frontend plugs into LLVM for the IR to machine code part, no need for GCC.

It replaces clang, it is not a fork of it.

Re: TinyCompiler: A compiler in a week-end

#92
post #88
post #69

Earlier quoted context omitted.

Which confirms complex matters aren't an issue, being able to handle them might be.

wrong, point missed by miles away. Maybe, "normal"/"average" devs would help you to get the point.

Those can keep up with Go, as per the language authors point of view regarding target audience.

Re: TinyCompiler: A compiler in a week-end

#93
post #67
post #60

Earlier quoted context omitted.

Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.

Relativity was discovered by a single guy.

Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said.

That doesn't diminish Einstein's achievement of course.

Re: TinyCompiler: A compiler in a week-end

#95
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…

lovely from-scratch implementation, without the magic and complexity of lex and yacc. brings back memories from 30+ years ago when I implemented a subset of C in C using lex and yacc in a compiler course.

in your blog, i would have liked to see the BNF grammar (without having to peek into the code).

now, heres your next assignment :) - do the same for functional programming (lambda calc) or logic programming (prolog). That would round out the education on languages and compilers for computation.

Re: TinyCompiler: A compiler in a week-end

#96
post #86

Earlier quoted context omitted.

I think it will introduce too many redundant phis, but I've never used it in practice - so I can only speculate. I'm not convinced DCE will clean maximal SSA up substantially. Even the classic Cytron et al algorithm must be combined with liveness analysis to avoid placing dead phis (that is, it does not produce pruned SSA by default). In the past, there was always a fear that SSA has the potential to cause quadratic…

I'll definitely test maximal SSA + DCE in tinyoptimizer when I'll get to it. For the moment I made [1] somewhat-pruned mem2reg pass, not even sure how to call it. But it indeed required to compute dominance frontiers. [1] https://ssloy.github.io/tinyoptimizer/mem2reg/

Nice.

I'm always happy to see more accessible resources for compiler writers.

---

As an aside: for displaying CFGs on the page, it would be very interesting to emit something somewhat dynamic. SVGs are always a good start, but there is a neat library for doing hierarchical graph layout (dagre, with d3-dagre handling rendering as well). In my own efforts at pedagogy, I've been interested in producing CFGs in-browser whose basic blocks comprise a "unified diff" view of the block (this being achieved in realtime by maintaining a subset of LLVM whose CFGs are persistent). Then it is more obvious what has changed: at least in the case of mem2reg which shouldn't introduce new blocks or move too much around (I forget if it hoists allocas to the entry block or not).

It'd also be cool to distil what underlying ideas you have found to be most useful in your efforts. The constrained scope of them may be useful to me, as I've wanted to create a kind of "advent of compilers" for years (advent of code but with a heavy slant towards compiler tasks/algorithms).

Re: TinyCompiler: A compiler in a week-end

#97
post #17

Earlier quoted context omitted.

I think OP is just trying to demystify the complexity of compliers for the sake of an educational resource. It's high quality work, compressed to a very small line count

Well, Python and Pascal were designed as a teaching language, and ended up being remarkably good for actual programming.

Also Basic, wasn’t it?

Re: TinyCompiler: A compiler in a week-end

#98
post #67

Earlier quoted context omitted.

Relativity was discovered by a single guy.

Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said. That doesn't diminish Einstein's achievement of course.

I made a facetious comment to parry that of pjmlp, whom also made a facetious comment wrt to compiler complexity and what "one person" can do.

https://github.com/seanbaxter/circle

It is like if one tried claiming that Fabrice Bellard was an example of a median dev.

The number of C++ compilers written by one person is one. And because of this, it gives us no predictive power in what pjmlp was trying to assert.

I agree with you, Albert and Lorentz and Riemann got caught in the rhetorical crossfire.

Re: TinyCompiler: A compiler in a week-end

#99
post #89
post #68

Earlier quoted context omitted.

QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author. I would recommend libfirm over QBE by at least 10km. https://libfirm.github.io/ https://github.com/libfirm/libfirm

Missing RISC-V code generation. But it is written in plain and simple C99, so it is at least much less toxic than LLVM. I wonder how cparser (did not check if it was plain and simple C)+libfirm compare in performance to cproc+QBE on my benchmarks. May have to take some time to check that. Whatever the results, it is always good to have, again, a real life alternative for optimizing C toolchains. The main issues are t…

Haven't used it, but this looks rather complete https://github.com/libfirm/libfirm/tree/master/ir/be/riscv

Re: TinyCompiler: A compiler in a week-end

#100
post #98

Earlier quoted context omitted.

Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said. That doesn't diminish Einstein's achievement of course.

I made a facetious comment to parry that of pjmlp, whom also made a facetious comment wrt to compiler complexity and what "one person" can do. https://github.com/seanbaxter/circle It is like if one tried claiming that Fabrice Bellard was an example of a median dev. The number of C++ compilers written by one person is one. And because of this, it gives us no predictive power in what pjmlp was trying to assert. I agree…

Not exactly the same but here https://github.com/robertoraggi/cplusplus there is one person serious effort to create a C++-23 compiler front end.
Post reply on HN