fuhsnn

A builtin is definitely better for the efficiency alone. Vanilla chibicc needs 5GB to preprocess the example.c from map-macro, in comparison to compiling an amalgamation of itself only takes 50 MB. It of course wasn't optimized for memory use but it's a peak into how much token expansions are involved in the wizardry.

There was a "__VA_TAIL__" WG14 proposal[1] that made it pretty simple to build custom map-like expansions, the OP's map example would be like:

> #define T(x, ...) printf(#x " = %d\n", x); __VA_TAIL__()

> T(1, 2, 3, 4, x, y, z)

You can play with it in the proposal author's ellipsis[2] and my slimcc[3], it's simple enough to implement (only about 30 lines of C) so I kept it in despite not seeing signs of it getting accepted.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3307.htm

[2] https://codeberg.org/gustedt/ellipsis

[3] https://github.com/fuhsnn/slimcc

> Give us the SDK's already, why don't, ya .. standardly!!!

I think the trend is there, the other day I was surprised that Polyend Endless, the ~$300 prompt-your-pedal thing actually has a minimal SDK on Github too.

I did some bits with gen-1 logue-sdk, the NTS-1 could have been a platform like the OP but the processor is severely underpowered for the price in today's standard and discontinued shortly after.

Well, why treat the assembly version as the main implementation when you have a supposedly equivalent C version around? If this is released as a plain C project I would actually be interested to try it out.

Yeah it's the assembly file, I posted two links for comparison:

asm: https://github.com/LiterateDrivenDevelopment/kcc/blob/main/l...

C: https://github.com/LiterateDrivenDevelopment/kcc/blob/main/l...

> The part of it being written in ARM64 Assembly

There is a C version under literate/verification, for example "main" is [1][2]:

[1] assembly version: ./literate/driver/43-main.weft

[2] C version: ./literate/verification/50-self-hosting-main.weft

Isn't UBsan such a switch?

These look more like configure snapshots for Zig's bundled Clang than full ports of build system.

The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions.

[1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc...

[2] https://github.com/allyourcodebase/rnnoise/blob/47db9c212d7e...

[3] https://github.com/allyourcodebase/wayland/blob/f992cd71e199...

It did take many hours, but I learnt a lot in the process, found some bugs to report, and watched plenty of series concurrently. Overall it's a nice and worthwhile hobby!

For those who are making indie C compilers that don't pretend to be __GNUC__ but want to compile real world projects, slimcc's test script[1] and platform header hacks[2] might save you some time. [1] https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi...

[2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/pl...

Some more fun stories:

- Game projects default to using SIMD so for example SDL and STB you always need to pass -DSDL_DISABLE_IMMINTRIN_H and -DSTB_NO_SIMD

- math.h's NAN usually fall back to (0.0f / 0.0f), which will print "-nan" with printf, some projects test suite fail because of it (they expected "nan").

- NetBSD's sys/cdefs.h straight up #error's if you don't pretend to be GCC or PCC.

- Some projects can't compile without __attribute__((always_inline)) because they use it on non-static functions.

- Many projects probe -fvisibility in the build system and pass -fvisibility=hidden to compile, but in the headers they gate __attribute__((visibility(default))) behind __GNUC__ checks, so you'll get missing symbols.

- Some projects use if(0) { undefined_function() } to fake static_assert(), there is even a bug report from QEMU to Clang because it failed to optimize in -O0 a certain `if` written this way.

- Even if you define __STDC_NO_VLA__, projects might fall back to alloca() code path that's untested and broken (python and jemalloc both had this problem, already reported)

- Valkey has broken __builtin_ctzll fallback nobody noticed (reported).

- Zig's C bootstrap path expects the compiler to have GCC/Clang-tier optimization and stack overflows if you don't (reported).

- I contributed stdatomic.h code path for Ruby just to compile it with slimcc, pretty sure it's still the only user of the code path.

- I implemented __has_extension in the hope that projects can use it to query gnu_asm; but SQLite broke because they use __has_extension(c_atomic) to query GNU atomics builtin, but c_atomic actually is meant for C11 _Atomic (IMO they should use __has_builtin)

> IMHO this "schism" was completely unnecessary and only happened because of ignorance and hubris

Having attempted to implement it correctly in slimcc, there are indeed some edge cases[1][2] that justify not adapting it fully.

[1] Unordered side effects; evaluation of expressions with overlapped destination is implementation defined but not listed as such (the wording in standard is "can potentially not be evaluated").

[2] Both GCC and Clang still get this wrong in 2026: https://github.com/llvm/llvm-project/issues/190858

> The sad vicious cycle of compilers not exercising the hardware

There could theoretically be instruction selection passes that are biased toward rare instructions, specialized for fuzzing hardware, I'm surprised Intel doesn't already do that.

The page says "aims to provide 70%" though, funny how words spread.

There is a library conversion fork: https://github.com/sgraham/sqbe.

IMO when the intended usage is AOT with an external assembler, which is another subprocess, text-based IO is actually the more natural approach.

Some of us do spend hours on godbolt.org tweaking code like it was game character build.

That read like a supply-chain attack gold mine if you ask me.

rcc[1] is another real-JIT C compiler. antcc[2] and xcc[3] are worth mentioning for being fast-enough to run C like scripting.

[1] https://github.com/dstogov/rcc

[2] https://codeberg.org/lsof/antcc

[3] https://github.com/tyfkda/xcc

Looking at the repo, the author seemed a little fed up [1] with the nature of lower level language and quitted.

[1] https://github.com/asibahi/paella/blob/main/writeup/c19.md#u...

Yeah, to get arcane macro tricks right I probably spent more than a full month total fighting with linked lists, never want to touch that part again.

Can't speak for kefir; slimcc has been `make unittest`ing Neovim v0.10.4 with no source modification in a Debian VM (so it's pretty portable, thanks!)

On tcc, the most common dealbreaker is no thread local support, having independent assembler/linker is a wonderful feat but not being feature parity with binutils could lead to build failure, contributors generally less willing to support the correct behavior for ABI, C standards and GCC extensions.

I hope these don't sound like a diss, if I had been better at reading its coding style I would definitely try to contribute to mob branch.

c-testsuite itself was curated from simple-cc and tinycc's test files, the latter originated from picoc.

I have found portability bugs in many projects with slimcc just because it exposed different preprocessor defines, some gate critical __attribute__ behind __GNUC__ check, some have buggy fallback to __builtin functions or VLA that nobody noticed in years, these could have been avoided with just an automatic build job in the CI with kefir or slimcc, (tcc is awesome but less suited for being a drop-in).

It is also important to have more independent implementations of the C standard, not only to sort out dark corners in the specification (current WG14 have been doing great), but to prevent it turning into GCC-Clang power struggle.

Congrats for the new optimizing pipeline, and thanks for the acknowledgment! It's nice to have company in the non-__GNUC__ camp.

TinyCC's mob branch on repo.or.cz just got trolled with AI commits today. Nowhere is safe it seems.

I don't fully grasp it either, the most appropriate analogy I can think of is like how OpenMP turns #pragma annotated loops into multi-threading, this work turns bytecode interpreting loops into JIT VM.

Took me a while to figure out whether it's interpreters for C programs or if there's a particular class of interpreters called "C". Turns out it's about interpreters implemented in C that they use modified LLVM to do the retrofitting, but couldn't it be applicable for other languages with LLVM IR, or other switch-in-a-loop patterns in C?

The website you linked says mallocng?

Don't get mimalloc and mallocng mixed up though, completely different animals.

Thanks, that actually look like a very solid baseline to start things with. Are you aware of onramp[1]? They use a custom VM to base compiler and shell on, it's extra steps, but could be more flexible long term.

[1] https://github.com/ludocode/onramp