1. Compile millions of lines per second, complete with debug information
2. Deoptimizes code when in a debugger (Read More)

Nimble-C can compile most C projects at millions of lines per second. We can't produce an exact number because no (open source) codebase has been large enough to take more than a second without significant linking (the linux kernel is quite a project.)

On our slower test machine, we can compile sqlite amalgamation in <100ms using one thread; it's a single C file that is just under 9mb with >250k lines. Our multi-threaded test compiles several versions of sqlite, which continues to take <100ms provided the work is roughly 250KLOC per core.

Builds are so fast that for most projects it's quicker to do a unity build (compiling all source files at once, which reduces linking) than it is to do an incremental build. Nimble-C can do incremental builds if that's what your workflow prefers.

C++ codebases vary wildly. If your codebase is 8 million lines or less and you have little to moderate meta-programming and templates, we estimate it'll compile in 1-6 seconds. This assumes a unity build, moderate dependencies/linking, and being compiled on a current generation CPU with DDR5 RAM.

We're slowly adding extensions to be more strict, such as no raw pointers (for C++ source files) and static bounds checking. Here's an example of a C function using a pointer without a length

int find(int*array, int value) {
	for(int i=0; i <= LAST; i++) {
		if (array[i] == value)
			return i;
	}
	return -1;
}

One rule is to enforce bounds checking on pointers with a known length, which would allow the above, since there's no length parameter. If you enforce bounds checking on all pointers, you can fix the code by adding size_t (or int) len, and replacing LAST with len. If you didn't notice the <= you'd get an error since i <= len is an off by 1 error.

There are other acceptable patterns; the following shows indexing with a literal. Notice access isn't inside a conditional

int check_header(int*array, int len, int value) {
	if (len < 3) return -1;
	/* at this point len must be at least 3 */
	return array[0] == 'A' && array[2] == 'C';
}

A third feature we like using is a function 'delete'. We noticed in some performance sensitive code, it's easy to accidentally make a copy by writing for (auto item : array) when the desired code was auto& item. By writing // NIMBLE DELETE(ArrayType::ArrayType(const ArrayType&)), the copy constructor will be deleted for that scope, and that line will cause an error. You may also write WARN if you prefer a warning.

Q: Do I need a special debugger for deoptimization?
A: No, lldb (and gdb on linux) should work fine.

Q: Which standards are supported? Can I use this as a drop-in replacement for clang?
A: C and C++ 2017 and earlier should work, and 2020 mostly works. There are parts of C++20 that clang does not support, and we don't support all of clang's compiler extensions and intrinsics (AVX512 being one of them). The CLI is designed to be a drop-in replacement for clang and gcc

Q: Where Can I Download?
A: Speak to sales

Q: What tools do you offer?
A: No tools outside of the compiler. Within the compiler, we have extensions that utilize static analysis, as well as coverage reporting. Clang provides an LSP and other tools that work fine on C and C++ codebases.

Q: Are you writing a compiler for <another popular language>?
A: No, we're only interested in C and C++. If you're asking if you can use our backend to support another language, please contact sales