> Wrong. You can build an abstraction layer above C code-generator which makes sure undefined C code doesn't get generated.
Yes, you could. But now you're talking way more work, and yet another IR. If you're going to build another IR for this, and you really really want to compile to C, why not just fix up LLVM's C backend and save yourself a lot of work?
> Nope. Once you have generated C code, you debug your C code with gdb or whatever is available. No problems there.
Debugging the generated C code is not a good experience. A developer wants to develop the code they wrote. For that to work you need fine-grained control over the contents of the DWARF DIEs.
> Nope. C compilation is about an order of magnitude faster than C++ compilation.
I'm not comparing C++ compilation to C compilation. I'm comparing the time it takes to compile C to LLVM IR, plus the overhead of in-memory or disk serialization, against zero (which is what you have if you go straight to LLVM IR).
> LLVM IR creates an additional abstraction barrier between a game programmer's code and hardware.
A C compiler IR, like LLVM IR, is not an additional abstraction barrier. What do you think C compilers compile their code into?
> But now you're talking way more work, and yet another IR.
What makes you think every abstraction layer has to be an IR? There's a reason we moved away from "assembly language" looking things: so we can think at a higher layer of abstraction and not worry about how a machine implements it.
> A developer wants to develop the code they wrote.
Again you're looking at it the wrong way. The generated C code _is_ the developer's code. An amplify-C developer would generate C code with the very purpose of looking at it. And the reason it has to be C and not an "assembly language" looking thing is that it has to be 'human readable'.
This is an entire approach quite orthogonal to the previous two approaches:
- shoehorn hand-picked fixed abstractions (like OO, templates) on top of C using cryptic syntax (the C++ approach)
- working at a higher layer and never having to deal with C but instead generating IR for a virtual machine (the Java, Perl, Python, LLVM-client, approach).
It turns out both approaches have turned out to be quite unsatisfactory for game programming. If you don't like this new approach, so be it, but unless you have an evidence of how game-programming is thriving on top of a VM model, you have to give them a break.
Yes, you could. But now you're talking way more work, and yet another IR. If you're going to build another IR for this, and you really really want to compile to C, why not just fix up LLVM's C backend and save yourself a lot of work?
> Nope. Once you have generated C code, you debug your C code with gdb or whatever is available. No problems there.
Debugging the generated C code is not a good experience. A developer wants to develop the code they wrote. For that to work you need fine-grained control over the contents of the DWARF DIEs.
> Nope. C compilation is about an order of magnitude faster than C++ compilation.
I'm not comparing C++ compilation to C compilation. I'm comparing the time it takes to compile C to LLVM IR, plus the overhead of in-memory or disk serialization, against zero (which is what you have if you go straight to LLVM IR).
> LLVM IR creates an additional abstraction barrier between a game programmer's code and hardware.
A C compiler IR, like LLVM IR, is not an additional abstraction barrier. What do you think C compilers compile their code into?