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

TinyCompiler: A compiler in a week-end

ssloy.github.io

Post reply on HN
Print view View original

101–110 of 120 posts

Re: TinyCompiler: A compiler in a week-end

#101

Post by sitkack »

kragen wrote: post #81
sitkack wrote: 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

It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?

9x larger in LoC, 50x larger in comments.

I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM.

Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments.

https://github.com/bytecodealliance/wasmtime/tree/main/crane...

Re: TinyCompiler: A compiler in a week-end

#102

Post by madmountaingoat »

musicale wrote: post #43
zabzonk wrote: post #39

Earlier quoted context omitted.

From wikipedia: "Pascal was influenced by the ALGOL W efforts, with the explicit goals of teaching programming in a structured fashion and for the development of system software.[5] A generation of students used Pascal as an introductory language in undergraduate courses." Its grammar made it relatively easy to write compilers for the language, which could be done as undergraduate exercises. Of course, this did not m…

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.

Re: TinyCompiler: A compiler in a week-end

#103

Post by fuhsnn »

mingodad wrote: post #100
sitkack wrote: post #98

Earlier quoted context omitted.

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.

It does look serious, and is able to parse one simple case I got at hand that openwatcom and orangec failed, thanks for bringing it up.

Re: TinyCompiler: A compiler in a week-end

#104

Post by ratmice »

sitkack wrote: post #65
RossBencina wrote: post #30

Earlier quoted context omitted.

> There are better books I would probably recommend I'm curious what you'd recommend. For what it's worth my goal was to compile to machine code. Anything less would have seemed insufficient. Later I got Appel's "Modern Compiler Implementation in Java" and Allen and Kennedy "Optimizing Compilers for Modern Architectures". Cooper and Torczon "Engineering a Compiler" was recommended here recently. I haven't seen it.

There is a whole body of non-academic work aimed at practioners for implementing compilers. Nils Holm's work https://t3x.org/ Teaching and Learning Compilers Incrementally - Jeremy Siek - RacketCon 2023 https://www.youtube.com/watch?v=43VA_QaTRT8 Nanopass https://nanopass.org/ original paper that was the basis for nanopass http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf https://www.reddit.com/r/ProgrammingLanguages/…

I don't think that the ghuloum 2006 paper was the initial basis for nanopass, at least the paper A Nanopass Framework for Compiler Education∗ seems to predate it in 2004 https://dl.acm.org/doi/10.1145/1016848.1016878

Re: TinyCompiler: A compiler in a week-end

#105

Post by kragen »

sitkack wrote: post #101
kragen wrote: post #81

Earlier quoted context omitted.

It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?

9x larger in LoC, 50x larger in comments. I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM. Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments. ht…

If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM.

Cranelift has been looking interesting. Also, LuaJIT.

Re: TinyCompiler: A compiler in a week-end

#106

Post by sitkack »

kragen wrote: post #105
sitkack wrote: post #101

Earlier quoted context omitted.

9x larger in LoC, 50x larger in comments. I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM. Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments. ht…

If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM. Cranelift has been looking interesting. Also, LuaJIT.

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.

Re: TinyCompiler: A compiler in a week-end

#107

Post by sylware »

sitkack wrote: post #99
sylware wrote: post #89

Earlier quoted context omitted.

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

Oh... What I read did not mention that many backends. Don't read the doc, read the code... :(

Definitely worth some benchmarks, until libfirm SDK is reasonable: there is a bad start with cmake (c++) and I have no idea if it requires expensive dependencies (even if those are written in plain and simple C).

Re: TinyCompiler: A compiler in a week-end

#108

Post by sylware »

pjmlp wrote: post #91
sylware wrote: post #90

Earlier quoted context omitted.

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.

I thought it was using libfirm... not that c++ diarrhea of llvm... :(

Re: TinyCompiler: A compiler in a week-end

#109

Post by sylware »

pjmlp wrote: post #92
sylware wrote: post #88

Earlier quoted context omitted.

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.

AI????

Re: TinyCompiler: A compiler in a week-end

#110

Post by kragen »

sitkack wrote: post #106
kragen wrote: post #105

Earlier quoted context omitted.

If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM. Cranelift has been looking interesting. Also, LuaJIT.

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.
Post reply on HN