Amplifying C (2010)
voodoo-slide.blogspot.com
voodoo-slide.blogspot.com
In other words, this is a compiler.
At this point I have to say what I always say: Don't compile to C. You will spend forever eliminating undefined behavior, the debugging experience will be bad because you don't have direct control over the DWARF DIEs, your compilation will be slower for no reason, you will not be able to add custom metadata to be consumed by optimization passes (for example, aliasing passes), you won't have access to special instructions like LLVM add nuw/nsw, etc.
Virtually all languages I know of that started out compiling to C stopped doing it at some point in their development, for one or more of the above reasons. Skip the major technical overhaul you're going to inevitably have to do and just build LLVM IR from the beginning. The LLVM API is excellent, so it ends up being less work to begin with.
The LLVM API is good, yes, but from a project management point of view it's pretty painful to work with --- the libraries are vast, don't have stable binary interfaces, and don't validate parameters, which means that if you get anything wrong it tends to just segfault deep inside somewhere. I've had to single step through the LLVM source code way too many times.
Plus, distribution support has always been pretty poor. e.g. Debian's 3.3 package's llvm-config tries to link your program against the static libraries rather than the dynamic ones, which leads to painfully large link times.
This all adds up to a non-trivial cost.
By contrast, emitting C is a lot less powerful, but suddenly you don't have to care about any of this stuff. You have a standardised intermediate format which you can throw at any compiler, which is trivially verifiable, doesn't need special libraries to write, and easily integrates into third-party tool chains. Simply having rigorously separated front and back ends can be a huge win. But biggest of all, you don't have to keep knowledge of the LLVM API in your brain while you're trying to get work done.
Of course, you don't get proper debugging information, or tail calls, or any of the other things you can do with the LLVM API which you can't do through C; but depending on what you want to do, it can totally be worth it.
Did you compile LLVM in Debug+Asserts mode? I rarely ever get segfaults from LLVM in this mode: I just get assertions when constructing invalid IR nodes.
> Plus, distribution support has always been pretty poor. e.g. Debian's 3.3 package's llvm-config tries to link your program against the static libraries rather than the dynamic ones, which leads to painfully large link times.
The link times aren't so bad if you use gold.
> You have a standardised intermediate format which you can throw at any compiler, which is trivially verifiable
I wouldn't say it's trivially verifiable. The undefined behavior rules of C are vast, and compiler authors have to know them incredibly well.
> But biggest of all, you don't have to keep knowledge of the LLVM API in your brain while you're trying to get work done.
But you have to keep C's undefined behavior rules in the back of your brain (such as signed overflow == UB!), which is worse.
Its not a compiler it a pre-processor.
People look at C in isolation but don't realise it was designed to be part of the full Unix system that included Sed, Awk, M4, Lex, Yacc, Sh and all the other tools.
Writing custom C abstractions with Awk is fairly trivial and you end up with efficient C code that can be further processed or tuned. Thats what tools like Awk are there for.
The compiler itself is built on the same principles doing successive transformations on source, IR, assembly etc. There is really no rigid boundary.
If you want C with custom abstractions a custom dialect that compiles to C makes perfect sense. That use case was taken into account in its design.
I fail to see how that quote has any contextual connection with the current article or compiler design. A discussion about the merits of Unix text streams or text in general is another discussion entirely then the current one.
Take a look at 'The AWK Programming Language ' Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger.
http://www.amazon.com/The-AWK-Programming-Language-Alfred/dp...
Yes, its that Aho and Kerninghan...
operators to C function mapping. you can run like so.
$ awk -f fixed.awk < fixst.in > fixed.c
--- fixed.awk ---
BEGIN {
printf("#include <stdio.h>\n");
printf("typedef long fixed;\n");
printf("void *send(fixed *this, char *message, ...);\n");
}
/^{/ {
Ndecl = 0;
printf("{\n");
}
/^}/ {
while(--Ndecl >= 0)
printf("\t%s\n", Destructor[Ndecl]);
printf("}\n");
}
/^:/ {
if($2~/fixed/) {
sub(/;/, "", $3);
printf("\tfixed *%s = send(NULL, \"fixed\");\n", $3);
Destructor[Ndecl++] = "send(" $3 ", \"~fixed\");"
}
else if ($4 ~ /(double)/) {
sub(/;/, "", $5);
printf("\tsend(%s, \"double\", &%s);\n", $5, $2);
}
else if ($3 ~ /^=/) {
sub(/;/, "", $4);
printf("\tsend(%s, \"=\", %s);\n", $2, $4);
}
else if ($3 ~ /^\+/) {
sub(/;/, "", $4);
printf("\tsend(%s, \"+=\", %s);\n", $2, $4);
}
else if ($3 ~ /^\*/) {
sub(/;/, "", $4);
printf("\tsend(%s, \"*=\", %s);\n", $2, $4);
}
}
/^[^{}:]/ { print }
int main()
{
: fixed a;
: fixed b;
: fixed t0;
: fixed t1;
double f;
: a = 1.00;
: b = 9.99;
: t0 = 0.00;
: t1 = 2.00;
: t0 += t1;
: t0 *= b;
: t0 += a;
: f = (double)t0;
}I am in favor of integrating tightly with a compiler whenever possible, but the selling point of c-amplify is to be independent from any compiler or your existing toolchain. This means that (1) you can work with a in-house proprietary compiler for specific hardware like a game console (author used to develop games) and (2) you code according to some stable C standard and not against a possibly evolving compiler. I suppose the LLVM API is quite stable, but things might break over time.
The LLVM API breakage issue is legitimate, but not enough to outweigh the downsides of compiling to C. The definition of LLVM IR doesn't change that much for the C features.
[1]: http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain....
C is an OK target for a small new language; it's probably too crummy for a big, successful one (C++ certainly is one data point here!) But IMO for 90% of new "small" languages that can choose between C and LLVM IR, C isn't obviously the worse choice.
If you are in that niche space (i.e. you know that you absolutely have to target some architecture), and you don't have source to your compiler, by all means target C though--though I really wonder if it isn't worth just fixing up the LLVM C backend. (LLVM hasn't been able to find a maintainer for that backend because so few people are on architectures that aren't supported natively by LLVM, which says something to me about how few people need support for those architectures.)
A few months ago when I was trying to compile swiftc's IR with emscripten, I would have said "definitely yes". It didn't work both because of a LLVM version mismatch and because, well, the NaCl backend passes were apparently only tested on IR generated by Clang - random differences in what swiftc generated, like using 'add' with a constant right hand side instead of get-element-ptr, not simplifying struct returns to return-via-pointer-argument, etc. made it variously abort or outright crash. As you know, Rust has never really worked with it either due to the version mismatch.
Admittedly, though, that's mainly emscripten's fault, and I expect the new WebAssembly backend in trunk to be much more robust. Other than that, a few reasons I can think of to want to compile to C:
- Performance. Other compiler backends often produce more efficient code than LLVM; not always, but it's nice to be able to test several independent production-quality C compilers and pick the fastest, while with LLVM IR you're stuck with what you have. Same goes for compilation speed, though LLVM usually ranks well at that, and even working around optimizer bugs.
- Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future.
- (edit) Easier to integrate with unusual platform-specific compilation modes, like C++/CLI or Apple's LLVM bitcode distribution (well, that is LLVM, but imagine in the future someone comes up with a similar system based on a different compiler).
- You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process. Like distributing object files, but those only work on one platform, while C works anywhere. (Caveat: compilers often need to know data layout, which in practice means you might need to have separate C outputs for 64-bit and 32-bit pointer sizes, and not support any more exotic data representations. But that's still way more portable than an object file.) Notably, even if you only need to distribute to people using LLVM, LLVM IR is not designed to be cross-platform.
Incidentally, for this reason, I'd love if someone made a Rust to C compiler, preferably working on the AST level to avoid the unreadable spaghetti that the LLVM C backend used to generate. It's easier to say "swap out this insecure C library with a secure Rust library" (to a larger C/C++ program) if doing so is a matter of swapping C files - distributing 'binaries' is suboptimal from a maintainability perspective, but not much worse than, e.g., SQLite's "amalgamation" distribution.
I wouldn't say "often" here. LLVM's compiler backend is top-notch and is hard to beat. Often it comes down to random register allocation or scheduling differences.
> - Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future.
What are you referring to in particular? The only thing I can really think of is exception handling, and that got overhauled recently for MSVC compatibility. PDB was an issue too, but that's gotten fixed and now LLVM can output PDB. I can't think of much that's left...
> - You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process.
That is a legitimate advantage. But on the whole I think that it's outweighed by the downsides of compiling to C.
This is what I was referring to. The RFC from a Microsoft employee on full CodeView (what gets compiled to PDB) support was posted three months ago, but AFAIK the implementation is still in progress. The preexisting support for CodeView is described by the documentation as "minimal" as it contains only line tables.
Strict aliasing and pointer rules, on the other hand, definitely are hard if you want to produce truly standard C code: you have to completely bypass C's type system, using `char *` or `uintptr_t` for everything, and while this can be done, the resulting code is likely to look pretty ugly. However, a reasonable alternative is to depend on nonstandard annotations to disable TBAA: `__attribute__((may_alias))` for every popular compiler other than MSVC, which I believe doesn't do TBAA at all. (If MSVC ever adds it, the generated C code would need updating, but that's not the end of the world.)
As for MIR - while I said AST, I suspect it would be fine to do it on MIR, at the cost of having to reconstruct some control flow. The biggest problem with doing it on LLVM IR is the simplified type info, while the full info is still there for MIR, right? Not an expert. Anyway, it's just an idea.
Wrong. You can build an abstraction layer above C code-generator which makes sure undefined C code doesn't get generated.
> the debugging experience will be bad because you don't have direct control over the DWARF DIEs.
Nope. Once you have generated C code, you debug your C code with gdb or whatever is available. No problems there.
> your compilation will be slower for no reason
Nope. C compilation is about an order of magnitude faster than C++ compilation.
> you will not be able to add custom metadata to be consumed by optimization passes
Does that mean the clang project asks C/C++ programmers to insert custom metadata into their C/C++ source files to give hints to clang?
> you won't have access to special instructions like LLVM add nuw/nsw
You're looking at it the wrong way. This article for C++ programmers who are sick and tired of C++'s arbitrary man-made complexity and limitations over abstraction management. They can handle generated C code quite well. They're not interested in looking at or working on assembly languages like LLVM IR, especially the one they'll have to learn before they resume their work.
LLVM IR creates an additional abstraction barrier between a game programmer's code and hardware. Getting rid of C++ and moving to LLVM IR (not to mention LLVM codebase itself is a giant C++ blob, and might want to switch to a saner system like, e.g., amplify-C) is not a very good strategy for a game project.
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?
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.
It has a 1-to-1 mapping to C (variables, literals, and all) so it seems to be doing less on the "compilation" end than what an assembler performs.
The three big problems in C are "how big is it", "who released it", and "who locks it". The language provides no help with any of these issues. C++ allows papering over the problem, but the abstractions always leak and the mold always comes through the wallpaper. There are times when you need a raw pointer (for system calls, for example) and the availability of raw pointers breaks the size and ownership protection.
Rust deals effectively with all three of those issues. That was a major breakthrough, one of the few fundamental advances in language design in years. Rust, unfortunately, seems to have taken a turn for the worse in the last year. Rust has been infected with the Boost disease - overly clever templates. Rust is a procedural language, but template enthusiasts have been making it pseudo-functional with constructs like ".and_then()" and ".or_else()". Then there's "try!()", with its invisible return statement. The result is painful to read and hard to maintain.
The author of the parent article has a point about "with-" type constructs. Python has a general "with" statement, which can be used on any object that implements "__enter__" and "__exit__". That's a very useful and safe language feature. Both Go and Rust lack it, and their workarounds ("defer" and destructors) are worse.
Python's "with" plays well with exceptions. Exceptions in Python work well. Exceptions in C++, not so much, mainly because ownership and exceptions mix badly. Go could fix that with GC, and Rust could fix that with the borrow checker. But neither has exceptions. As a result, error handling in Go is wordy, and in Rust, both complicated and wordy.
I had high hopes for Rust, but they may have jumped the shark by getting too clever. We don't need a new C, but we may need a new Rust. At this point, any new low level language that doesn't have a borrow checker is flawed from the start.
If »starting with C« means »use a mostly similar syntax for basic things«, then yes. Otherwise only ObjC has been on that road, given that C supports things that C# and Java don't. And then it's a »start with C, remove stuff you don't like, and add stuff you need«, which is probably more akin to »start wherever and pick things you want in the language«. E.g. syntax aside, C# probably has much more in common with Delphi in its inception and design than with C.
This defines a toolkit for defining a C-derived language per-project. This on its own adds no new features to C; it only gives you the means to add them.
This way he has already added lambdas, lazy evaluation, types, anaphoric macros, with- macros.
I prefer the former approach because it's less likely to alienate C programmers. At the same time, being able to define new syntax can have the same effect, since every new syntax you add carves out a smaller and smaller set of the community that is willing to use it. The same is true for Common Lisp reader macros, which is why few of the many syntax extensions that are available become commonly used.
[0]: http://www.european-lisp-symposium.org/editions/2014/ELS2014...
[1]: http://www.european-lisp-symposium.org/editions/2014/selgrad...
// c++
AutoFile file("c:/temp/foo.txt", "w");
fprintf(file, "Hello, world");
// lisp
(with-open-file (f "c:/temp/foo.txt" "w")
(fprintf f "Hello, world"))
{ AutoFile file("c:/temp/foo.txt", "w");
fprintf(file, "Hello, world"); }
(with-open-file (f "c:/temp/foo.txt" "w")
(fprintf f "Hello, world"))In C++ with RAII, the "emphasis" makes even more sense, to the extent that it doesn't make things ugly.
I guess the argument might be readability of the output, but I'm guessing as his lisp grows more complex the output is going to diverge from the input quite a bit anyway (I'm trying to imagine what a closure would look like.. I'm guessing it wouldn't be pretty)
Embeddable Common Lisp (ECL) [1] is an efficient implementation of Lisp that compiles to C. It can be easily used to interface C and Lisp.
Regarding C++, nowadays there is Clasp [2] that is under active development and looks very promising.
[1] https://common-lisp.net/project/ecl/ [2] https://github.com/drmeister/clasp
Article dates from 2010... I wonder whether this ever got used.
(There's a paper that suggests doing something similar for C++, though not quite so adventurously. It makes it look more like Pascal: http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...)
What he wants is C's conceptual model with sexpr syntax and (therefore) the ability to build custom abstractions on top of it. That's different from working in an entirely other programming language with its own conceptual model that happens to compile to C.
You would see this difference vividly in the C that the two systems generate: the first would read like a more verbose version of the same application in which the skeleton of the program is recognizable; the second would look like machine gobbledygook. The former would be debuggable in a way that let you step through the logic of the surface program, while the other probably wouldn't. And so on.
Instead of thinking of this as a different language, think of it as 'magic C with DSLs', or 'C, with a macro system that lets you do what you want'. That distinction isn't absolute, because if you push your abstractions far enough you will end up with a different language, but the style of programming the author is talking about gives you incentives not to do that.
So what's the best way to tackle the learning curve of what you're suggesting? If I know zero about LLVM and I want to make something like the OP, what should I do?
It walks you through basic expression generation, control flow, memory, etc. for a simple language. The learning curve isn't zero, to be sure, but I think the time saved by being able to work with IR as a tree instead of as a flat series of bytes makes it easily worth it.
My first attempt at using LLVM was using the C++ API. It was...a struggle. Using this approach (IR snippets), I made more progress in a day than I had in months using the API.
I did debugging before it got to C and just ensured C generation would do exactly what I wanted. I could read and debug the C itself as a check against problems in that. Yet, serializing and deserializing my IR just didn't happen: it was just LISP or BASIC expressions depending on which version we're talking about. Just tree's.
You're debugging regression claim is correct as I addressed in my main comment. Fortunately, my development style and choice of libraries compensated for that nicely. It would've been quite painful if I had to deal with arbitrary FOSS or proprietary stuff out of necessity. I'd be working at both abstraction levels for sure or coding miracles into my tooling haha.
> You can use Terra and Lua as…
> A scripting-language with high-performance extensions. While the performance of Lua and other dynamic languages is always getting better, a low-level of abstraction gives you predictable control of performance when you need it. Terra programs use the same LLVM backend that Apple uses for its C compilers. This means that Terra code performs similarly to equivalent C code. For instance, our translations of the nbody and fannhakunen programs from the programming language shootout1 perform within 5% of the speed of their C equivalents when compiled with Clang, LLVM’s C frontend. Terra also includes built-in support for SIMD operations, and other low-level features like non-temporal writes and prefetches. You can use Lua to organize and configure your application, and then call into Terra code when you need controllable performance.
> An embedded JIT-compiler for building languages. We use techniques from multi-stage programming to make it possible to meta-program Terra using Lua. Terra expressions, types, and functions are all first-class Lua values, making it possible to generate arbitrary programs at runtime. This allows you to compile domain-specific languages (DSLs) written in Lua into high-performance Terra code. Furthermore, since Terra is built on the Lua ecosystem, it is easy to embed Terra-Lua programs in other software as a library. This design allows you to add a JIT-compiler into your existing software. You can use it to add a JIT-compiled DSL to your application, or to auto-tune high-performance code dynamically.
> A stand-alone low-level language. Terra was designed so that it can run independently from Lua. In fact, if your final program doesn’t need Lua, you can save Terra code into a .o file or executable. In addition to ensuring a clean separation between high- and low-level code, this design lets you use Terra as a stand-alone low-level language. In this use-case, Lua serves as a powerful meta-programming language. You can think of it as a replacement for C++ template metaprogramming or C preprocessor X-Macros4 with better syntax and nicer properties such as hygiene. Since Terra exists only as code embedded in a Lua meta-program, features that are normally built into low-level languages can be implemented as Lua libraries. This design keeps the core of Terra simple, while enabling powerful behavior such as conditional compilation, namespaces, templating, and even class systems implemented as libraries.
I self identify as a Lisper (Clojure), but have done a fair amount of professional work in C/C++/Go too. I was productive in Lua/Terra practically overnight. I ported a bunch of Rust (that I had originally ported from C and was considering porting back to C + custom string-templating) to Lua in a few days and the code got shorter, simpler, faster, and with build times of a tiny fraction of those in Rust. Terra just matches how I think about programming low-level code: Types are about shifting work to compile time. Yes, some error-detection work, sure, but that's totally secondary for me as compared to shifting work to compile time for performance, memory representation, etc.
"Every C++ shop has its own 'accepted' subset."
And it's frustrating. This quote from the article too:
"these are clear signs that C++ isn’t providing any real cost benefit for us, and that we should be writing code in other ways."
If the language is a rich one, then every shop uses part of it.
If the language has a rich library ecosystem, then each shop has its own little garden of libraries.
But I agree with the DSLs, that is the curse of many Common Lisp shops, yet Lisp is a very simple language.
$ wc -l stb_image.h
6433 stb_image.h
$ more stb_image.c
#define STBI_ONLY_JPEG
#define STBI_ONLY_PNG
#define STBI_FAILURE_USERMSG
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"
$ time clang -c stb_image.c -o stb_image.o
real 0m0.091s
user 0m0.075s
sys 0m0.014s
Pascal and C are fast because they're old and relatively simple, and their implementations are mature.
C++ becomes super slow when you start doing anything interesting, when I tried Rust it seemed very slow, even Java is slow although it seems like it shouldn't have to be. Those languages are all more widely used than D, I think.
[edit: typo]
haven't gambit/chicken already tried something similar for scheme ? don't know what the latest state of affairs there is though.
The C function does not have any defined semantics for certain values of a and b. The Common Lisp function merely adds two integers (or runs out of memory trying).
Here's main benefits a LISP-like C can give you:
1. Automate boilerplate 2. Automate safety 3. 4GL-style doing very much with very little 4. Context-specific optimizations 5. My favorite: interactive testing & incremental compilation for sub-1s code-to-execute and maximizing mental flow. Safe, C alternatives will probably never be able to do this. 6. Update while the system is running if still in prototyping mode. Fun stuff. 7. Save exact execution state of mock C application for debugging if you design that feature.
I don't recall most of details of implementation due to a broken memory. I worked in industrial BASIC more than C because C has too many issues. However, as "dang" and "jhack" are into this, I'll add that I did find it useful as a non-compiler-expert to setup at least two versions or states of the development environment: prototyping and production.
The prototyping system was designed for interactive development. It had all the libraries I might use loaded up, pre-wrapped, and with interface checks. The 3GL commands, or emulation of them, ran instantly as LISP expressions. You develop in this mode with no connection to the 3GL except logical and [mostly] semantic equivalence. Your code is straight up code at the moment.
When done with that, you switch to production where your code is data that's interpreted and turned into the 3GL. The generator should take care to make portable code or at least cover your targets. Throw in out-of-bounds checks and such by default. Can have a declaration to decide that. Anyway, you get your BASIC, C, C++, whatever code here. I can even imagine one for Rust that works faster than the actual compiler.
So, two versions of the system: interactive interpretation, incremental compilation, and live updating of LISP version for quick development w/ optional checks inside (eg typing); version that generates code for external compilers. Both operate on same input but ignore what they don't need. Can avoid most debugging issues with a robust, coding style and plenty interface checks. All I did with that.
Hope lessons from that old project helps someone doing the next. I expect if I recreate it that the Amplifying C stuff will be helpful in figuring out how to do that. So might be tools like Racket and me learning LISP for real. ;)
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
"Including Common Lisp." http://paulgraham.com/quotes.html