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

Oops, I Wrote a C++ Compiler

praeclarum.org

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Oops, I Wrote a C++ Compiler

#31

Post by jcranmer »

amag wrote: post #21
lilyball wrote: post #11

Earlier quoted context omitted.

The successor to LLVM isn't going to be written by someone just hacking on an app and decides they could use a basic compiler. It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design. Encouraging people to use LLVM instead of home-growing a toy compiler can still get…

> It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design. And from where would they get those ideas? Tweaking LLVM is not enough to learn the necessary trade-offs. You need to write a compiler from the ground up. In fact you need to do it multiple times. Most likely…

Most compilers use not one internal IR, but rather a successive series of IRs. LLVM itself has its normal IR layer, plus a machine IR layer for actually generating code for targets. Plus another layer (two actually, you can pick which one you want) for going between LLVM IR to machine IR. Most programming language frontends have their own IR (or two) that they use in between the AST and something like LLVM IR.

The genius of LLVM is that it's a stable, well-defined IR layer in the middle of the compilation stack that lets you switch out either the frontend or the backend without having to do the entire messy, boring, critical implementation of the other piece. And you can support pretty wacky frontend languages or pretty wacky backends (people compile LLVM to C source or FPGAs, for example).

Re: Oops, I Wrote a C++ Compiler

#32

Post by jcranmer »

mhh__ wrote: post #27
saagarjha wrote: post #16

Earlier quoted context omitted.

To be honest, that's most C++ compilers.

That's only technically true. The main C++ compilers in common use basically support, aim to support or have collectively agreed not to support parts of the C++ standard.

> have collectively agreed not to support parts of the C++ standard.

Those parts were ripped out of the standard. (The big one is export templates, where the expert compiler implementers when asked for feedback about how to implement it said "don't").

Re: Oops, I Wrote a C++ Compiler

#33

Post by ncmncm »

Does this seem insane to anyone else?

Emulating an Arduino, you get no benefit at all from re-implementing a compiler. The Instruction Set Architecture is rigorously defined. All you need to do is implement that, plus some peripherals. Write a compiler from ATmega machine code to your VM, if you like.

This C++-- will never be actually useful to anyone, and people developing for Arduino already have more than one anyway. It might be educational, but almost all the work has gone into the least useful and least educational parts of it.

The destructor is by far the single most essential feature of C++. After that, constructors, templates, and the standard library take 2nd, 3rd, and 4th place. If you think integer conversions are important, you have not learned much at all.

There are already several ATmega emulators done sanely. One more would not be bad, and could break new ground. Use virtualization primitives to make an x86 program translated from ATmega think it's a real chip, and emulate the Arduino 100x faster than the real one.

Re: Oops, I Wrote a C++ Compiler

#34

Post by groovy2shoes »

lilyball wrote: post #11
peterkelly wrote: post #9

Earlier quoted context omitted.

> Why not use GCC or LLVM as part of your project? That's not how the world gets compiler people. Someone had to write GCC and LLVM, and someone will have to write whatever comes next. Languages and tooling only advance because there are those who choose to take the hard road instead of "just using that thing that someone else made".

The successor to LLVM isn't going to be written by someone just hacking on an app and decides they could use a basic compiler. It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design. Encouraging people to use LLVM instead of home-growing a toy compiler can still get…

> Hello everybody out there using minix -

> I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.

—Linus Torvalds, in a post[1] to comp.os.minix, 25 August 1991 (emphasis mine)

[1]: https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...

Re: Oops, I Wrote a C++ Compiler

#35

Post by mynegation »

It takes hundreds, if not thousands person-years to write C++ compiler intentionally, damn next to impossible to write it accidentally as title implies.

Frank is a talented engineer, I used to follow his work on Calca very closely. But as others noted, this does not seem to be anywhere close to C++. The problem with parsing C++ starts with C. Say you see the code “T(t);” at the beginning of a function body. What is it? Declaration of variable t of type T? Call of function T on variable t? You cannot parse it properly without symbol table. No context free parser handles C properly, let alone C++. It gets progressively and exponentially worse from here.

Re: Oops, I Wrote a C++ Compiler

#36

Post by userbinator »

mynegation wrote: post #35

It takes hundreds, if not thousands person-years to write C++ compiler intentionally, damn next to impossible to write it accidentally as title implies. Frank is a talented engineer, I used to follow his work on Calca very closely. But as others noted, this does not seem to be anywhere close to C++. The problem with parsing C++ starts with C. Say you see the code “T(t);” at the beginning of a function body. What is i…

Parsing is the easy part of a C++ compiler, and the T t example you mentioned has a relatively simple solution (which is, as you say, using the symbol table). In fact that ambiguity is present in C as well (with typedefs), and yet it hasn't really stopped many others from writing their own C compilers which handle that case.

It's the things like templates, multiple/virtual inheritance, and argument-dependent lookup/overload resolution which are difficult to get right, and the reason that even somewhat fully-featured C++ compilers are rare.

Re: Oops, I Wrote a C++ Compiler

#37

Post by jlarocco »

amelius wrote: post #3

Please don't call it C++ if it doesn't even support constructors and destructors. People will be trying to port their existing code, and will be unpleasantly surprised. > But the truth is, I’m just going to keep listening to users and improving the parts I can. I am not trying to recreate GCC or LLVM. Why not use GCC or LLVM as part of your project? That seems like a better investment of your time.

> People will be trying to port their existing code, and will be unpleasantly surprised.

I agree with you 100%, but this made me laugh.

Re: Oops, I Wrote a C++ Compiler

#38

Post by sedachv »

mynegation wrote: post #35

It takes hundreds, if not thousands person-years to write C++ compiler intentionally, damn next to impossible to write it accidentally as title implies. Frank is a talented engineer, I used to follow his work on Calca very closely. But as others noted, this does not seem to be anywhere close to C++. The problem with parsing C++ starts with C. Say you see the code “T(t);” at the beginning of a function body. What is i…

> You cannot parse it properly without symbol table. No context free parser handles C properly, let alone C++. It gets progressively and exponentially worse from here.

C is actually pretty easy if you ignore all of the bad advice to use parser generators. I looked into the various YACC grammars for C I could find on the Internet, and all of them either had bugs or were incomplete. TCC[1] has a simple recursive-descent parser. With a recursive descent parser you also have the option of implementing the C pre-processor in the same step. Turns out I was able to implement a single-pass C parser and pre-processor as a bunch of Common Lisp read macros[2].

I have not looked into it, but the approach for C++ looks like it would be very different because template instantiation needs its own step.

[1] https://bellard.org/tcc/ [2] https://github.com/vsedach/Vacietis/blob/master/compiler/rea...

Re: Oops, I Wrote a C++ Compiler

#39

Post by ezoe »

jchw wrote: post #6
amelius wrote: post #3

Please don't call it C++ if it doesn't even support constructors and destructors. People will be trying to port their existing code, and will be unpleasantly surprised. > But the truth is, I’m just going to keep listening to users and improving the parts I can. I am not trying to recreate GCC or LLVM. Why not use GCC or LLVM as part of your project? That seems like a better investment of your time.

It is very well explained? GCC and Clang would be nightmares to integrate into an app that runs on many platforms including iOS, and even once you did, you'd still need to implement an interpreter, because you're not allowed to JIT on the app store. Compiling a toolchain for a desktop platform is easy. Cross compiling a toolchain is moderately easy. But embedding a toolchain into an iOS app, where you have to get it…

Why people still use stupid Apple products which unbelievably forbid the certain computation on the machine we own(except we don't) and have complete control of(also we don't).

Re: Oops, I Wrote a C++ Compiler

#40

Post by pjmlp »

jcranmer wrote: post #31
amag wrote: post #21

Earlier quoted context omitted.

> It's going to be written by someone who has the explicit goal of replacing LLVM, fully understands LLVM's design and tradeoffs, and has ideas about an architecture for a successor that improves on the design. And from where would they get those ideas? Tweaking LLVM is not enough to learn the necessary trade-offs. You need to write a compiler from the ground up. In fact you need to do it multiple times. Most likely…

Most compilers use not one internal IR, but rather a successive series of IRs. LLVM itself has its normal IR layer, plus a machine IR layer for actually generating code for targets. Plus another layer (two actually, you can pick which one you want) for going between LLVM IR to machine IR. Most programming language frontends have their own IR (or two) that they use in between the AST and something like LLVM IR. The ge…

Not really that much of a genius, given that IBM was already using the same architecture on their RISC compilers research during the 70's.

Check the papers related to PL.8 compiler architecture.

Post reply on HN