fuhsnn
Joined 2 years ago
Karma
563
Submissions
212
Member since
Aug 4
Recent submissions
Comment · 14 days ago
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.
Comment · 14 days ago
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
Comment · 25 days ago
> 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.
Comment · 25 days ago
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.
Comment · 1 month ago
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.
Comment · 1 month ago
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...
Comment · 1 month ago
> 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
Comment · 1 month ago
Isn't UBsan such a switch?
Comment · 3 months ago
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...
Comment · 5 months ago
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!
Comment · 5 months ago
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)
Comment · 5 months ago
> 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
Comment · 5 months ago
> 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.
Comment · 5 months ago
The page says "aims to provide 70%" though, funny how words spread.
Comment · 5 months ago
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.